1. 20 Aug, 2020 1 commit
    • Dominik Inführ's avatar
      [logging] Make Log::IsEnabled() atomic · 41d2e5c9
      Dominik Inführ authored
      With concurrent allocation background threads invoke Log::IsEnabled()
      as well. Fix data race here by making is_enabled_ atomic, such that
      IsEnabled() remains cheap.
      
      After locking the mutex in MessageBuilder, IsEnabled() needs to be
      checked again in case an old value was read. Otherwise we might log
      even though logging was already disabled on another thread.
      
      The other direction where a log message isn't logged is deemed
      acceptable.
      
      Bug: v8:10315
      Change-Id: I32c9dd2e9879fbdb4ca94e080a16ddd875de7c30
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2362948
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69495}
      41d2e5c9
  2. 17 Aug, 2020 3 commits
  3. 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
  4. 11 Aug, 2020 1 commit
  5. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  6. 04 Aug, 2020 1 commit
  7. 01 Aug, 2020 1 commit
    • Ulan Degenbaev's avatar
      [ukm] Rename v8::Context::Token to v8::metrics::Recorder::ContextId · 260ec995
      Ulan Degenbaev authored
      Chrome is currently adding a 128-bit V8ContextToken to keep track of
      V8 contexts across multiple isolates and processes. Having per-isolate
      token exposed by V8 leads to confusion of these two tokens.
      
      This moves v8::Context::Token to v8::metrics::Recorder and changes
      the corresponding functions:
      - v8::Context::GetToken => v8::metrics::Recorder::GetContextId
      - v8::Context::GetByToken => v8::metrics::Recorder::GetContext
      
      This CL is purely mechanical and does not change the behaviour.
      
      Bug: chromium:1101749
      Tbr: clemensb@chromium.org
      Change-Id: I31bbfa02ebab1c0d91b00f0d08c1b236392d14d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2330023
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarEmanuel Ziegler <ecmziegler@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69188}
      260ec995
  8. 28 Jul, 2020 3 commits
  9. 22 Jul, 2020 2 commits
    • Ross McIlroy's avatar
      [TurboProp] Add initial DefineOutput phase for fast register allocator · c092c081
      Ross McIlroy authored
      Adds the first phase of the fast register allocator, which runs through
      
      the instruction stream and defines a VirtualRegisterData for each
      virtual register based on how that virtual register is produced. Also
      adds logic to pipeline.cc to allocate and use FastRegistorAllocatorData
      for use throughout the fast register allocation phases.
      
      BUG=v8:9684
      
      Change-Id: I2f4533467346d5f3fdf50a0a1fedd7e4082f0187
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2295364
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69010}
      c092c081
    • Seth Brenith's avatar
      Profile-guided optimization of builtins · 922983df
      Seth Brenith authored
      Design doc:
      https://docs.google.com/document/d/1szInbXZfaErWW70d30hJsOLL0Es-l5_g8d2rXm1ZBqI/edit?usp=sharing
      
      V8 can already collect data about how many times each basic block in the
      builtins is run. This change enables using that data for profile-guided
      optimization. New comments in BUILD.gn describe how to use this feature.
      
      A few implementation details worth mentioning, which aren't covered in
      the design doc:
      
      - BasicBlockProfilerData currently contains an array of RPO numbers.
        However, this array is always just [0, 1, 2, 3, ...], so this change
        removes that array. A new DCHECK in BasicBlockInstrumentor::Instrument
        ensures that the removal is valid.
      
      - RPO numbers, while useful for printing data that matches with the
        stringified schedule, are not useful for matching profiling data with
        blocks that haven't been scheduled yet. This change adds a new array
        of block IDs in BasicBlockProfilerData, so that block counters can be
        used for PGO.
      
      - Basic block counters need to be written to a file so that they can be
        provided to a subsequent run of mksnapshot, but the design doc doesn't
        specify the transfer format or what file is used. In this change, I
        propose using the existing v8.log file for that purpose. Block count
        records look like this:
      
        block,TestLessThanHandler,37,29405
      
        This line indicates that block ID 37 in TestLessThanHandler was run
        29405 times. If multiple lines refer to the same block, the reader
        adds them all together. I like this format because it's easy to use:
        - V8 already has robust logic for creating the log file, naming it to
          avoid conflicts in multi-process situations, etc.
        - Line order doesn't matter, and interleaved writes from various
          logging sources are fine, given that V8 writes each line atomically.
        - Combining multiple sources of profiling data is as simple as
          concatenating their v8.log files together.
      
      - It is a good idea to avoid making any changes based on profiling data
        if the function being compiled doesn't match the one that was
        profiled, since it is common to use profiling data downloaded from a
        central lab which is updated only periodically. To check whether a
        function matches, I propose using a hash of the Graph state right
        before scheduling. This might be stricter than necessary, as some
        changes to the function might be small enough that the profile data is
        still relevant, but I'd rather err on the side of not making incorrect
        changes. This hash is also written to the v8.log file, in a line that
        looks like this:
      
        builtin_hash,LdaZeroHandler,3387822046
      
      Bug: v8:10470
      Change-Id: I429e5ce5efa94e01e7489deb3996012cf860cf13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2220765
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69008}
      922983df
  10. 21 Jul, 2020 1 commit
  11. 14 Jul, 2020 1 commit
  12. 10 Jul, 2020 1 commit
  13. 07 Jul, 2020 2 commits
  14. 03 Jun, 2020 1 commit
  15. 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
  16. 07 May, 2020 1 commit
  17. 06 May, 2020 2 commits
  18. 30 Apr, 2020 1 commit
  19. 24 Apr, 2020 1 commit
  20. 23 Apr, 2020 1 commit
  21. 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
  22. 08 Apr, 2020 1 commit
  23. 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
  24. 06 Mar, 2020 1 commit
  25. 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
  26. 25 Feb, 2020 1 commit
  27. 24 Feb, 2020 1 commit
  28. 21 Feb, 2020 1 commit
  29. 20 Feb, 2020 2 commits
  30. 13 Feb, 2020 1 commit
  31. 11 Feb, 2020 1 commit