1. 24 Jul, 2020 1 commit
    • Leszek Swirski's avatar
      [compiler] Off-thread finalize each function immediately · 198deea2
      Leszek Swirski authored
      Allow "iterative" finalization when off-thread finalization is enabled,
      meaning that each compiled function is finalized immediately after
      compilation, rather than all functions being first compiled and then
      finalized.
      
      This is what we do on the main thread, and it reduces peak Zone memory
      usage by being able to discard empty compilation Zones earlier.
      
      One necessary functionality for this was being able to defer the
      finalization of asm.js functions until the main thread pause, since
      they can't be finalized off-thread -- previously we would just bail
      out of doing the off-thread finalization if any inner function was
      asm.js.
      
      Bug: chromium:1011762
      Change-Id: I21ff69d62eaa93b5ff908624b7115601e36f70f1
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282536Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69032}
      198deea2
  2. 15 Jul, 2020 1 commit
  3. 13 Jul, 2020 1 commit
  4. 06 Jul, 2020 1 commit
  5. 09 Mar, 2020 1 commit
  6. 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
  7. 02 Mar, 2020 1 commit
  8. 25 Feb, 2020 1 commit
  9. 14 Feb, 2020 1 commit
  10. 13 Feb, 2020 1 commit
  11. 12 Feb, 2020 3 commits
  12. 22 Jan, 2020 2 commits
  13. 16 Jan, 2020 1 commit
  14. 08 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [objects] Clean-up SFI::Init/SFI::SetScript · 6c836372
      Leszek Swirski authored
      Clean up isolate inference and non-allocating/allocating parts of
      SharedFunctionInfo::InitFromFunctionLiteral, so that it can more easily
      be refactored for off-thread allocation in the future. Also, make
      SharedFunctionInfo::SetScript a member function, to acknowledge that it
      is non-allocating.
      
      Bug: chromium:1011762
      Change-Id: I26624fceb642dfdf257ec3d96aab31ea90e48870
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1991482
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65639}
      6c836372
  15. 06 Dec, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Add bitfield declarations · 57074692
      Seth Brenith authored
      This change is the first part of adding Torque support for a "bitfield
      struct", which represents a set of bitfields packed together into an
      integer value. With this change, Torque can generate the list of
      BitField template specializations that allow runtime code to use the
      bitfield values. The flags used in SharedFunctionInfo are converted to
      Torque to exercise this functionality. Bitfield values are not yet
      accessible directly from Torque code.
      
      Bug: v8:7793
      Change-Id: I9e4a3df7c847111b6e02e513f175dbf938b0be35
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1949047
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65371}
      57074692
  16. 28 Nov, 2019 1 commit
  17. 20 Nov, 2019 1 commit
  18. 15 Nov, 2019 2 commits
  19. 12 Nov, 2019 1 commit
  20. 06 Nov, 2019 1 commit
    • Simon Zünd's avatar
      Introduce REPL mode · fbcc2e87
      Simon Zünd authored
      Design doc: bit.ly/v8-repl-mode
      
      This CL adds a new REPL mode that can be used via
      DebugEvaluate::GlobalREPL. REPL mode only implements re-declaration
      of 'let' bindings at the moment. Example:
      
      REPL Input 1: let x = 21;
      REPL Input 2: let x = 42;
      
      This would normally throw a SyntaxError, but works in REPL mode.
      
      The implementation is done by:
        - Setting a 'repl mode' bit on {Script}, {ScopeInfo}, {ParseInfo}
          and script {Scope}.
        - Each global let declaration still gets a slot reserved in the
          respective {ScriptContext}.
        - When a new REPL mode {ScriptContext} is created, name clashes
          for let bindings are not reported as errors.
        - Declarations, loads and stores for global let in REPL mode are
          now "load/store global" instead of accessing their respective
          context slot directly. This causes a lookup in the ScriptContextTable
          where the found slot for each name is guaranteed to be the same
          (the first one).
      
      Bug: chromium:1004193, chromium:1018158
      Change-Id: Ia6ab526b9f696400dbb8bfb611a4d43606119a47
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876061
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64793}
      fbcc2e87
  21. 05 Nov, 2019 1 commit
  22. 22 Oct, 2019 1 commit
  23. 07 Oct, 2019 1 commit
  24. 13 Sep, 2019 1 commit
  25. 11 Sep, 2019 1 commit
  26. 06 Sep, 2019 1 commit
  27. 04 Sep, 2019 1 commit
  28. 23 Aug, 2019 1 commit
  29. 12 Aug, 2019 1 commit
  30. 21 Jun, 2019 1 commit
    • Ross McIlroy's avatar
      [SFI] Always store function_literal_id in SFI. · f92d7196
      Ross McIlroy authored
      Calling FindIndexInScript performs a linear search on the script functions and can
      take considerable time. With Bytecode flushing we will lose the function_literal_id
      and have to call FindIndexInScript if we ever recompile the flushed function. This
      can take a significant proportion of the recompilation time and has caused regressions
      in rendering times for some web applications (e.g, 395ms in FindIndexInScript for 132ms
      spent lazily re-compiling code).
      
      To avoid this, add function_literal_id back into the SFI and remove it from
      UnoptimizedCompileInfo. This will slightly regress memory usage (particularly
      in cases where many of the SFIs are compiled), however it means we can remove
      the FindIndexInScript function and avoid these long-tail regressions when
      bytecode is flushed.
      
      BUG=chromium:965833
      
      Change-Id: Ia31e82eb6c871a6d698a518326a8555822a7a1d8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669700Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62319}
      f92d7196
  31. 04 Jun, 2019 1 commit
    • Leszek Swirski's avatar
      [tracing] Speed up SharedFunctionInfo::TraceID · 43cd5d10
      Leszek Swirski authored
      Avoid the linear lookup of function literal id when getting the shared
      function info TraceID, by optionally passing through a FunctionLiteral.
      Additionally, use the FunctionLiteralId helper when a FunctionLiteral is
      not available, since it can also fast-path in some cases.
      
      As a drive-by, allow using a ScriptIterator without an Isolate pointer
      (e.g. manually creating a handle) to allow calling FunctionLiteralId
      without an Isolate pointer.
      
      Bug: v8:9325
      Change-Id: Ibfa053f300d6d5005485c67174a848264a5d1372
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643429
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61983}
      43cd5d10
  32. 23 May, 2019 2 commits
  33. 22 May, 2019 1 commit
  34. 21 May, 2019 1 commit
  35. 14 May, 2019 1 commit