1. 04 Aug, 2021 3 commits
    • Benedikt Meurer's avatar
      [inspector] Fix positions for inline scripts with #sourceURL. · c2f30c2b
      Benedikt Meurer authored
      For inline scripts that have a `// #sourceURL=foo.js` annotation, the
      V8 inspector (and by extension `Error.stack`) currently operates in
      terms of the `foo.js`, i.e. doesn't give any hint about the actual
      source, except for the line/column offsets reported upon scriptParsed.
      However in case of stack frames (i.e. as part of `Error.stack` or as
      part of the call frames reported via CDP), the line/column offsets are
      relative to the actual source instead of relative to the `foo.js` part,
      which - besides other things - makes post-processing of recorded stack
      traces tricky (sometimes impossible).
      
      This change adjusts the source positions reported for (inline) scripts
      with sourceURL annotations to be relative to the (inline) script instead
      of the surrounding document.
      
      Bug: chromium:1183990
      Fixed: chromium:578269
      Change-Id: I74f2b93c22ec43ca796b6b51faa9df5b99cf03f9
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069289
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76097}
      c2f30c2b
    • Jakob Gruber's avatar
      [compiler] Silence tsan warning on Context::length · bb32a2dd
      Jakob Gruber authored
      The field is immutable after initialization and thus should be set
      non-atomically on the main thread, and read non-atomically on the
      background thread. But TSAN support for generated code turns all field
      accesses into relaxed atomic accesses, leading to this race detection.
      Silence it by making the read relaxed as well.
      
      Bug: chromium:1236302,v8:7790
      Change-Id: I47979b2dbf61a65a9e92453324fe2b255fafd30d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3070700
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76080}
      bb32a2dd
    • Mythri A's avatar
      [sparkplug] Add support to flush only baseline code · ef7d6579
      Mythri A authored
      Add support to flush only baseline code. FLAG_flush_baseline_code
      controls if baseline code is flushed or not and FLAG_flush_bytecode
      controls if bytecode is flushed or not. With this CL it is possible
      to control if we want to flush only bytecode / only baseline code / both.
      This also lets us have different heuristics for bytecode and baseline
      code flushing.
      
      Bug: v8:11947
      Change-Id: Ibdfb9d8be7e7d54196db7890541fa0b5d84f037e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060481Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#76075}
      ef7d6579
  2. 03 Aug, 2021 3 commits
  3. 02 Aug, 2021 3 commits
  4. 30 Jul, 2021 2 commits
  5. 29 Jul, 2021 4 commits
  6. 28 Jul, 2021 1 commit
    • Jakob Gruber's avatar
      [compiler] Thread-safe Map::ComputeMinObjectSlack · e8fd9368
      Jakob Gruber authored
      ComputeMinObjectSlack is called concurrently from background threads
      (when --concurrent-inlining) and must therefore be thread-safe.
      
      This CL adds a compiler-specific thread-safe variant
      of ComputeMinObjectSlack in addition to the plain old non-thread-safe
      one. Thread-safety is achieved through locking: on the bg thread, a
      shared lock when traversing transitions, and on the main thread, an
      additional exclusive critical section when overwriting prototype
      transitions.
      
      Tbr: leszeks@chromium.org
      Bug: v8:7790,v8:12010,chromium:1231901
      Change-Id: If5af83df1ab896b22477921449fb5ba4c8d3e8a3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045342
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Auto-Submit: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75949}
      e8fd9368
  7. 27 Jul, 2021 1 commit
  8. 26 Jul, 2021 4 commits
  9. 23 Jul, 2021 3 commits
  10. 22 Jul, 2021 3 commits
  11. 21 Jul, 2021 3 commits
    • Seth Brenith's avatar
      [torque] Invert the default for @generateCppClass · f30f4815
      Seth Brenith authored
      Since most Torque-defined extern classes use @generateCppClass, it makes
      more sense to instead annotate the small number that don't. This is part
      of the cleanup work that Nico recommended in [1].
      
      Classes that still have to opt out:
      
      - Those that can be converted by https://crrev.com/c/3015666
      - HeapObject: sort of special since it's the root of the inheritance
        hierarchy. Generated code would include two declarations that don't
        compile until HeapObject is defined:
          bool IsHeapObject_NonInline(HeapObject o);
          explicit TorqueGeneratedHeapObject(
              Address ptr, HeapObject::AllowInlineSmiStorage allow_smi);
      - SmallOrdered*: these classes use templates on the C++ side, which is
        not currently representable in Torque.
      - SwissNameDictionary: according to a comment, the Torque generation for
        this class is incorrect. I haven't investigated further.
      
      Drive-by fix: make the Torque formatter keep LF on Windows rather than
      writing CRLF.
      
      [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit#
      
      Bug: v8:8952
      Change-Id: I1fbb5290f0c645842b84c53816c09bb3398206a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3028721Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#75841}
      f30f4815
    • Nico Hartmann's avatar
      Revert "[offthread] Template deserializer on Isolate" · c73d759b
      Nico Hartmann authored
      This reverts commit e24fa913.
      
      Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/18917/overview
      
      Original change's description:
      > [offthread] Template deserializer on Isolate
      >
      > Make the deserializer class templated on Isolate/LocalIsolate. This
      > allows the ObjectSerializer to be split into a main-thread and offthread
      > variant, with the latter taking a LocalIsolate.
      >
      > Eventually, we probably want to anyway split off the code-cache de/serializer
      > to a separate implementation (for various reasons), and this the only one that
      > wants off-thread finalization, and at this point the deserializer can revert
      > back to being un-templated, used only for bootstrapping. However, this is the
      > simplest way, for now, to enable off-thread deserialization.
      >
      > Bug: chromium:1075999
      > Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#75834}
      
      Bug: chromium:1075999
      Change-Id: Id699ebe0c17d3a61ec35b0f78417306175271647
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041675Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75836}
      c73d759b
    • Leszek Swirski's avatar
      [offthread] Template deserializer on Isolate · e24fa913
      Leszek Swirski authored
      Make the deserializer class templated on Isolate/LocalIsolate. This
      allows the ObjectSerializer to be split into a main-thread and offthread
      variant, with the latter taking a LocalIsolate.
      
      Eventually, we probably want to anyway split off the code-cache de/serializer
      to a separate implementation (for various reasons), and this the only one that
      wants off-thread finalization, and at this point the deserializer can revert
      back to being un-templated, used only for bootstrapping. However, this is the
      simplest way, for now, to enable off-thread deserialization.
      
      Bug: chromium:1075999
      Change-Id: I49c0d2c5409f0aa58183673785296756c3714f22
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2562254Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#75834}
      e24fa913
  12. 20 Jul, 2021 5 commits
  13. 19 Jul, 2021 5 commits