1. 03 Jun, 2020 1 commit
  2. 14 May, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add off thread deserialization · 595609fb
      Leszek Swirski authored
      Add a new OffThreadObjectDeserializer, which can deserialize a snapshot
      into an OffThreadIsolate.
      
      This involves templating the Deserializer base class on Isolate, and
      amending OffThreadHeap to be able to create Reservations same as the
      main-thread Heap can. Various off-thread incompatible methods are
      stubbed out as UNREACHABLE in OffThreadIsolate overloads.
      
      There is currently no API entry into the off-thread deserialization, but
      under --stress-background-compile it now runs the CodeDeserializer (i.e.
      code cache deserialization) in a background thread.
      
      Bug: chromium:1075999
      
      Change-Id: I2453f51ae31df4d4b6aa94b0804a9d6d3a03781e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172741
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67799}
      595609fb
  3. 07 May, 2020 1 commit
  4. 06 May, 2020 2 commits
  5. 30 Apr, 2020 1 commit
  6. 24 Apr, 2020 1 commit
  7. 23 Apr, 2020 1 commit
  8. 22 Apr, 2020 1 commit
    • Dan Elphick's avatar
      [snapshot] Rename partial snapshot to context snapshot · 71bd50e1
      Dan Elphick authored
      The partial snapshot/serializer/deserializer are renamed to context *,
      while the partial snapshot cache is renamed to startup object cache in
      line with the read-only object cache (as this better reflects where it
      lives and what it does).
      
      To avoid a gap in the file history due to renaming both the files and
      identifiers simulataneously, this leaves all the partial-*.* files in
      place. They will be renamed in a follow-up CL.
      
      Bug: v8:10416
      Change-Id: I5ef41cad751aaa24b35ee2b3c72bd0295832f2c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144115
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Auto-Submit: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67306}
      71bd50e1
  9. 08 Apr, 2020 1 commit
  10. 09 Mar, 2020 1 commit
    • Dan Elphick's avatar
      [api] Create v8::String::NewFromLiteral that returns Local<String> · b097a8e5
      Dan Elphick authored
      String::NewFromLiteral is a templated function that takes a char[N]
      argument that can be used as an alternative to String::NewFromUtf8 and
      returns a Local<String> rather than a MaybeLocal<String> reducing the
      number of ToLocalChecked() or other checks.
      
      Since the string length is known at compile time, it can statically
      assert that the length is less than String::kMaxLength, which means that
      it can never fail at runtime.
      
      This also converts all found uses of NewFromUtf8 taking a string literal
      or a variable initialized from a string literal to use the new API. In
      some cases the types of stored string literals are changed from const
      char* to const char[] to ensure the size is retained.
      
      This API does introduce a small difference compared to NewFromUtf8. For
      a case like "abc\0def", NewFromUtf8 (using length -1 to infer length)
      would treat this as a 3 character string, whereas the new API will treat
      it as a 7 character string.
      
      As a drive-by fix, this also fixes all redundant uses of
      v8::NewStringType::kNormal when passed to any of the String::New*
      functions.
      
      Change-Id: Id96a44bc068d9c4eaa634aea688e024675a0e5b3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2089935
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarMathias Bynens <mathias@chromium.org>
      Reviewed-by: 's avatarMythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66622}
      b097a8e5
  11. 06 Mar, 2020 1 commit
  12. 03 Mar, 2020 2 commits
    • Leszek Swirski's avatar
      [offthread] Allow off-thread bytecode finalization · 455cb6c0
      Leszek Swirski authored
      Add the remaining missing templatizations to allow an initial wiring in
      of the off-thread factory into streaming compilation finalization.
      
      The off-thread finalization is behind a flag, disabled by default:
          --finalize-streaming-on-background
      
      When the flag is enabled, background tasks will perform perform the
      finalization during their background execution, and will release the
      parser and compilation jobs once they are no longer needed.
      
      The implementation is complete enough for performance testing, but not
      enough for launch. Notably, there is no support for:
      
        * Class boilerplates (the code is marked unreachable),
        * Exceptions during finalization, i.e. parse/compile warnings/errors,
        * Allocation sampling,
        * Logging,
        * Asm.js,
        * Parallel complication tasks
        * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()")
      
      This patch also adds some tracing events for the various stages of the
      off-thread finalization (including the main-thread merge) for further
      performance improvements.
      
      Bug: chromium:1011762
      Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66566}
      455cb6c0
    • Clemens Backes's avatar
      [wasm] Remove samples for obsolete histograms · 547e857b
      Clemens Backes authored
      The histograms were removed from chrome. This CL cleans up the V8 code
      to stop reporting samples.
      
      R=ahaas@chromium.org
      
      Bug: chromium:1053285
      Change-Id: I7c6ff36ac9bb5d86e81e5f36849903a95a8ed618
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083478Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66553}
      547e857b
  13. 25 Feb, 2020 1 commit
  14. 24 Feb, 2020 1 commit
  15. 21 Feb, 2020 1 commit
  16. 20 Feb, 2020 2 commits
  17. 13 Feb, 2020 1 commit
  18. 11 Feb, 2020 1 commit
  19. 10 Feb, 2020 1 commit
  20. 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
  21. 08 Feb, 2020 1 commit
  22. 06 Feb, 2020 1 commit
    • Tobias Tebbi's avatar
      [profiler] fix 4 bugs in --prof/linux-tick-processor · 58b45cca
      Tobias Tebbi authored
      - In log.cc, we used InstructionStart() for code create events, but
        the Code object address for code move events. Change to use
        InstructionStart() for both.
      - The symbol table contains some kind of virtual address, not file
        offsets. They happened to be identical in the past but are no longer,
        probably due to toolchain changes. Now we use objdump to figure out
        the difference between virtual addresses and file offsets.
      - When a new code object happened to be created at the same address as
        a previous one, we wouldn't update it.
        This is indeed wrong, as predicted in a TODO by Jaro.
      - For 64bit addresses, using >>> is wrong, now replaced with division.
      
      
      Change-Id: Ib23114ed736f98bfc33c65004a039a3fd04d3c49
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2016586Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66145}
      58b45cca
  23. 30 Jan, 2020 1 commit
  24. 10 Jan, 2020 2 commits
  25. 07 Jan, 2020 1 commit
  26. 02 Jan, 2020 1 commit
  27. 04 Dec, 2019 1 commit
    • Joyee Cheung's avatar
      [class] implement inspector support for private instance methods · 963ff849
      Joyee Cheung authored
      This patch implements inspector support for private instance methods:
      
      - Previously to implement brand checking for instances with private
        instance methods we store the brand both as the value with the brand
        itself as the key in the stances. Now we make the value the context
        associated with the class instead.
      - To retrieve the private instance methods and accessors from the
        instances at runtime, we look into the contexts stored with the
        brands, and analyze the scope info to get the names as well as
        context slot indices of them.
      - This patch extends the `PrivatePropertyDescriptor` in the inspector
        protocol to include optional `get` and `set` fields, and make the
        `value` field optional (similar to `PropertyDescriptor`s).
        Private fields or private instance methods are returned in the
        `value` field while private accessors are returned in the `get`
        and/or `set` field. Property previews for the instaces containing
        private instance methods and accessors are also updated similarly,
        although no additional protocol change is necessary since the
        `PropertyPreview` type can already be used to display accessors.
      
      Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
      
      Bug: v8:9839, v8:8330
      Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407
      Commit-Queue: Joyee Cheung <joyee@igalia.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65337}
      963ff849
  28. 02 Dec, 2019 3 commits
  29. 27 Nov, 2019 1 commit
  30. 25 Nov, 2019 2 commits
  31. 22 Nov, 2019 1 commit
  32. 15 Nov, 2019 1 commit
  33. 31 Oct, 2019 1 commit