1. 03 May, 2022 1 commit
  2. 26 Mar, 2022 1 commit
  3. 10 Jan, 2022 1 commit
    • Benedikt Meurer's avatar
      [inspector] Capture stack trace only once for JSError objects. · 765ca6a0
      Benedikt Meurer authored
      When creating a new JSError object (or using the non-standard API
      `Error.captureStackTrace`) V8 would previously capture the "simple stack
      trace" (as FixedArray of CallSiteInfo instances) to be used for the non-
      standard `error.stack` property, and if the inspector was active also
      capture the "detailed stack trace" (as FixedArray of StackFrameInfo
      instances). This turns out to be quite a lot of overhead, both in terms
      of execution time as well as memory pressure, especially since the
      information needed for the inspector is a proper subset of the
      information needed by `error.stack`.
      
      So this CL addresses the above issue by capturing only the "simple stack
      trace" (in the common case) and computing the "detailed stack trace"
      from the "simple stack trace" when on demand. This is accomplished by
      introducing a new ErrorStackData container that is used to store the
      stack trace information on JSErrors when the inspector is active. When
      capturing stack trace for a JSError object while the inspector is
      active, we take the maximum of the program controlled stack trace limit
      and the inspector requested stack trace limit, and memorize the program
      controlled stack trace limit for later formatting (to ensure that the
      presence of the inspector is not observable by the program).
      
      On the `standalone.js` benchmark from crbug.com/1283162 (with the
      default max call stack size of 200) we reduce execution time by around
      16% compared to ToT. And compared to V8 9.9.4 (the version prior to the
      regression in crbug.com/1280831), we are 6% faster now.
      
      Doc: https://bit.ly/v8-cheaper-inspector-stack-traces
      Bug: chromium:1280831, chromium:1278650, chromium:1258599
      Bug: chromium:1280803, chromium:1280832, chromium:1280818
      Fixed: chromium:1283162
      Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78542}
      765ca6a0
  4. 15 Dec, 2021 1 commit
  5. 14 Dec, 2021 1 commit
  6. 08 Dec, 2021 1 commit
    • Benedikt Meurer's avatar
      [inspector] Consistent frame function name in V8 Inspector and API. · 54584461
      Benedikt Meurer authored
      On the way to a cheaper and more scalable stack frame representation
      for the inspector (crbug/1258599), this removes the need to expose
      both what was called "function name" and what was called "function
      debug name" on a v8::StackFrame instance.
      
      The reason to having a distinction between that the V8 API exposes
      and what the inspector exposes as frame function name is that after
      the initial refactoring around v8::internal::StackFrameInfo, some
      wasm cctests would still dig into the implementation details and
      insist on seeing the "function name" rather than the "function
      debug name". This CL now addresses that detail in the wasm cctests
      and going forward unifies the function names used by the inspector
      and the V8 API (which is not only needed for internal consistency
      and reduced storage requirements in the future, but also because
      Blink for example uses v8 API and v8_inspector API interchangeably
      and assumes that they agree, even though at this point Blink
      luckily wasn't paying attention to the function name):
      
      - The so-called "detailed stack trace", which is produced for the
        inspector and exposed by the v8 API, always yields the "function
        debug name" (which for example in case of wasm will be a WAT
        compatible name),
      - while the so-called "simple stack trace", which is what is used
        to implement the CallSite API and underlies Error.stack continues
        to stick to the "function name" which in case of wasm is not
        WAT compatible).
      
      Bug: chromium:1258599
      Change-Id: Ib15d038f3ec893703d0f7b03f6e7573a38e82b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312274Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/main@{#78283}
      54584461
  7. 06 Dec, 2021 1 commit
  8. 29 Sep, 2021 1 commit
    • Seth Brenith's avatar
      [torque] Get rid of @generatePrint annotation · 267b067b
      Seth Brenith authored
      I'm trying to remove annotations and make behavior more consistent. For
      @generatePrint, there are two options: either generate printers for
      every extern class, or never generate printers for extern classes. This
      change implements the option of always generating printers. Classes that
      require custom printing can easily hide the generated printer by using
      DECL_PRINTER. This causes the generated file
      gen/torque-generated/objects-printer.cc to grow to 1600 lines, including
      many functions that are never used, but I think the consistency benefit
      outweighs a little more compilation time on one file. This change also
      removes custom printers in cases where the generated printer includes
      all of the same content.
      
      If folks would prefer the option to never generate printers, I'm open to
      doing that instead. I like the notion that generating more code could
      reduce the friction of adding new classes and thereby encourage people
      to define precise types rather than using FixedArrays, but the current
      implementation of generated printers is limited, and many printers have
      been customized to show the data that matters the most. Unlike verifiers
      and body descriptors, there are no correctness or safety concerns with
      hand-written printers.
      
      Some bugs showed up once we start generating printers for everything,
      and this change fixes them:
      - Printers incorrectly included ungettable fields like padding
      - Printers called getters which might be hidden by hand-written classes
      - The generated getter for Map::instance_type used
        ReadField<InstanceType>, which is not an arithmetic type since it's an
        enum
      
      One more tiny drive-by fix: added a missing newline in the printers for
      JSMap and JSSet.
      
      Bug: v8:7793
      Change-Id: Ib9e9575fbcb57879935ff18bf4db49fe276d2966
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172190Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/main@{#77152}
      267b067b
  9. 18 Jun, 2021 1 commit
  10. 11 Mar, 2021 3 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored
      This is a reland of 80f5dfda. A condition
      in pipeline.cc was inverted, which lead to a CSA verifier error.
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      TBR=jgruber@chromium.org
      
      Bug: v8:11238
      Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
      Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored
      This reverts commit 80f5dfda.
      
      Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview
      
      Original change's description:
      > [no-wasm] Exclude src/wasm from compilation
      >
      > This is the biggest chunk, including
      > - all of src/wasm,
      > - torque file for wasm objects,
      > - torque file for wasm builtins,
      > - wasm builtins,
      > - wasm runtime functions,
      > - int64 lowering,
      > - simd scala lowering,
      > - WasmGraphBuilder (TF graph construction for wasm),
      > - wasm frame types,
      > - wasm interrupts,
      > - the JSWasmCall opcode,
      > - wasm backing store allocation.
      >
      > Those components are all recursively entangled, so I found no way to
      > split this change up further.
      >
      > Some includes that were recursively included by wasm headers needed to
      > be added explicitly now.
      >
      > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      > because it only tests wasm backing stores. This file is excluded from
      > no-wasm builds then.
      >
      > R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      >
      > Bug: v8:11238
      > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      > Commit-Queue: Clemens Backes <clemensb@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#73344}
      
      Bug: v8:11238
      Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
      Auto-Submit: Clemens Backes <clemensb@chromium.org>
      Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
      Cr-Commit-Position: refs/heads/master@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored
      This is the biggest chunk, including
      - all of src/wasm,
      - torque file for wasm objects,
      - torque file for wasm builtins,
      - wasm builtins,
      - wasm runtime functions,
      - int64 lowering,
      - simd scala lowering,
      - WasmGraphBuilder (TF graph construction for wasm),
      - wasm frame types,
      - wasm interrupts,
      - the JSWasmCall opcode,
      - wasm backing store allocation.
      
      Those components are all recursively entangled, so I found no way to
      split this change up further.
      
      Some includes that were recursively included by wasm headers needed to
      be added explicitly now.
      
      backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
      because it only tests wasm backing stores. This file is excluded from
      no-wasm builds then.
      
      R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
      
      Bug: v8:11238
      Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
      Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
  11. 03 Mar, 2021 1 commit
  12. 15 Feb, 2021 1 commit
    • Benedikt Meurer's avatar
      [stack-traces] Cache source position on StackFrameInfos. · 7b07c779
      Benedikt Meurer authored
      Previously we had cached the source position information on
      JSStackFrame (C++) objects and reused that between calls to
      GetLineNumber() and GetColumnNumber(). The refactoring in
      https://crrev.com/eed0d27c2f774b3adbc85d0a5fb30a8cf0f018a8
      effectively removed that cache, while still making things
      faster though.
      
      This CL puts back the caching on the StackFrameInfo objects
      by reusing the `offset` slot to store the computed source
      position (as indicated by a bit in the `flags`). For promise
      combinator async frames, the bit is always set and the
      `offset_or_source_position` slot thus always contains the source
      position (aka the `promise index` in this case). We also
      added a `StackFrameInfo::ComputeLocation()` method to remove the
      last remaining place where we'd peek into the StackFrameInfo from
      outside stack-frame-info.{cc,h}.
      
      Also-By: kimanh@chromium.org
      Bug: chromium:1077657, v8:8742, chromium:1069425
      Change-Id: I59e26a91965617163776e6cc2610b88e6925452c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695386
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72752}
      7b07c779
  13. 12 Feb, 2021 1 commit
    • Benedikt Meurer's avatar
      [stack-traces] Simplify and speedup stack trace collection. · eed0d27c
      Benedikt Meurer authored
      Following up on https://crrev.com/c/2689185, this CL significantly
      simplifies the whole implementation of the stack trace capturing.
      
      Before this CL, capturing any stack trace (for the purpose of the API or
      Error.stack) would roughly work like this:
      
        1. The CaptureStackTrace() function uses the StackFrameIterator to
           walk the system stack. For each native frame it uses the
           FrameSummary abstraction to get all (including potentially inlined)
           frames. For each of those it appends a record consisting of six
           elements to a FrameArray (this holds pointers to the actual
           closures and receivers).
        2. Afterwards the FrameArray is shrinked to the required size, and a
           new FixedArray is allocated, and initialized with new
           StackTraceFrame objects where each holds a reference to the
           FrameArray, the index of the frame, and an initially uninitialized
           StackFrameInfo reference. This new FixedArray is then returned from
           CaptureStackTrace() and either stored on a message object or
           provided to the API as v8::StackTrace.
      
      The new approach removes a lot of the machinery in between and directly
      creates a FixedArray of StackFrameInfo objects in CaptureStackTrace().
      These StackFrameInfo objects are directly exposed as v8::StackFrame on
      the public API, and they hold the six fields that were previously stored
      flat in the FrameArray. This not only avoids a lot of copying around of
      data and creation of temporary objects and handles, but most importantly
      unifies and simplifies the stack frame function inside StackFrameInfo,
      so you no longer need to wonder which function / object might be
      responsible for a certain API.
      
      There's still a lot of room for improvement. In particular we currently
      don't cache the source position for a given StackFrameInfo (or
      globally), but rather recompute it every time. This is still very fast,
      significantly faster than the previous approach.
      
      There are some notable (potentially user visible) changes:
      
        - The CallSite#GetPosition() method now consistently returns the
          Wasm module relative bytecode offset for all Wasm frames (previously
          it'd return the function relative bytecode offset for non-asm.js
          Wasm frames).
        - The column and line numbers returned from StackFrameInfo methods are
          consistently 1-based now, instead of sometimes being 0-based (Wasm)
          and sometimes being 1-based (JS and asm.js Wasm). The only
          potentially noticable difference is that for
          CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but
          that was wrong and useless anyways.
        - CallSite#GetThis() would sometimes return the_hole, another bug
          flushed out by this CL.
      
      The CL also contains some other not noteworthy drive-by-cleanups.
      
      Fixed: chromium:1057211
      Bug: chromium:1077657, chromium:1069425, v8:8742
      Bug: chromium:1127391, chromium:1098530, chromium:981541
      Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72694}
      eed0d27c
  14. 11 Feb, 2021 1 commit
    • Benedikt Meurer's avatar
      [stack-traces] Remove StackFrameInfo. · 11b6f176
      Benedikt Meurer authored
      For a long time, V8 had two distinct ways to capture and store a stack
      trace, one where we'd just collect and symbolize the information for the
      v8::StackTrace API (script id, name, line and colum information mostly),
      and one where V8 would also memorize the closures, receivers, and
      optionally the parameters of the stack frame, which we use for
      Error.stack and the non-standard CallSite APIs. Those two were often out
      of sync and suffered from various different issues. Eventually they were
      refactored into a single captureStackTrace() bottleneck that would
      produce a FrameArray.
      
      This CL is a logical continuation of the refactorings. It repairs a
      regression where we'd compute the method name (as part of the
      cached StackFrameInfo) even if we don't need them (as is the case for
      the inspector and any other use of the v8::StackTrace API).
      
      Everytime a method was invoked on StackTraceFrame, it'd call into
      StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo
      like this:
      
        1. Create a FrameArrayIterator and point it to the FrameArray at the
           index stored in the StackTraceFrame.
        2. Invoke FrameArrayIterator::Frame(), which copies the information
           from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame
           or WasmStackFrame C++ object, and use the StackFrameBase virtual
           methods to transfer all information to a newly created
           StackFrameInfo object.
        3. Kill the link to the FrameArray and put a link to the
           StackFrameInfo object into the StackTraceFrame.
      
      This caching turned out to be extremely costly, since beyond other
      things, it'd always invoke JSStackFrame::GetMethodName(), which is
      extremely costly (the execution time is linear in the number of
      properties on the receiver and it's prototype chain). The cost was so
      high that several work-arounds had been added, which would avoid
      triggering the eager construction of the StackFrameInfo object (i.e.
      https://crrev.com/c/2080663, https://crrev.com/c/2550504 or
      https://crrev.com/c/2261736, but also https://crrev.com/c/1688927).
      
      This CL removes the StackFrameInfo caching completely, since neither the
      inspector nor Error.stack benefit from the caching at all. It's only the
      first part in a series of refactorings that will significantly reduce
      the complexity and overhead of the stack trace collection.
      
      Doc: https://bit.ly/2wkbuIy
      Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742
      Bug: chromium:1127391, chromium:1098530, chromium:981541
      Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185
      Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72647}
      11b6f176
  15. 28 Oct, 2020 1 commit
    • Tobias Tebbi's avatar
      [torque] generate C++ class definitions per Torque file · 03f60296
      Tobias Tebbi authored
      This CL splits the class definitions per .tq file, to realize the
      following relationship:
      A class defined in src/objects/foo.tq has a C++ definition in
      src/objects/foo.h. Torque then generates:
      
      - torque-generated/src/objects/foo-tq.inc
        An include file (no proper header) to be included in src/objects/foo.h
        containing the Torque-generated C++ class definition.
      
      - torque-generated/src/objects/foo-tq-inl.inc
        An include file (no proper header) to be included in
        src/objects/foo-inl.h containing inline function definitions.
      
      - torque-generated/src/objects/foo-tq.cc
        A source file including src/objects/foo-inl.h that contains non-inline
        function definitions.
      
      Advantages of this approach:
      - Avoid big monolithic headers and preserve the work that went into
        splitting objects.h
      - Moving a definition to Torque keeps everything in the same place
        from a C++ viewpoint, including a fully Torque-generated C++ class
        definition.
      - The Torque-generated include files do not need to be independent
        headers, necessary includes or forward declarations can just be added
        to the headers that include them.
      
      Drive-by changes:
      A bunch of definitions and files had to be moved or created to realize
      a consistent 1:1 relationship between .tq files and C++ headers.
      
      
      Bug: v8:7793
      TBR: hpayer@chromium.org
      Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
      Reviewed-by: 's avatarSeth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#70853}
      03f60296
  16. 25 Sep, 2020 1 commit
    • Tobias Tebbi's avatar
      Reland "[torque] refactor: use -tq only in filenames derived from .tq files" · 21b58516
      Tobias Tebbi authored
      This is a reland of 64caf2b0
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      >
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      >
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      >
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      Bug: v8:7793
      TBR: hpayer@chromium.org jgruber@chromium.org
      Change-Id: I6c492bc64aee1ff167e7ef401825eca9097a7f38
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2431565
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70137}
      21b58516
  17. 22 Sep, 2020 2 commits
    • Francis McCabe's avatar
      Revert "[torque] refactor: use -tq only in filenames derived from .tq files" · 92aaace1
      Francis McCabe authored
      This reverts commit 64caf2b0.
      
      Reason for revert: Seems to be causing a failure:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/38809?
      
      Original change's description:
      > [torque] refactor: use -tq only in filenames derived from .tq files
      > 
      > This is to establish a naming rule for Torque-generated files:
      > - If the file is called foo/bar-tq..., then it is derived from a
      >   file foo/bar.tq
      > - Otherwise it doesn't belong to a specific .tq file.
      > 
      > So far, we attached -tq to all Torque-generated file names, where it
      > sometimes corresponded to a .tq file name and sometimes not.
      > It is not necessary to add -tq to file names to indicate that they are
      > Torque-generated, since they are already in a directory called
      > torque-generated, and we always refer to them as
      > "torque-generated/filename", so there is no confusion even though some
      > files now have the same name as a corresponding hand-written file, for
      > example factory.cc.
      > 
      > TBR: hpayer@chromium.org
      > Bug: v8:7793
      > Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      > Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#70060}
      
      TBR=jgruber@chromium.org,tebbi@chromium.org
      
      Change-Id: I6960fe540861947536c6ddfc0f4887ea80899fae
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7793
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2424486Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70065}
      92aaace1
    • Tobias Tebbi's avatar
      [torque] refactor: use -tq only in filenames derived from .tq files · 64caf2b0
      Tobias Tebbi authored
      This is to establish a naming rule for Torque-generated files:
      - If the file is called foo/bar-tq..., then it is derived from a
        file foo/bar.tq
      - Otherwise it doesn't belong to a specific .tq file.
      
      So far, we attached -tq to all Torque-generated file names, where it
      sometimes corresponded to a .tq file name and sometimes not.
      It is not necessary to add -tq to file names to indicate that they are
      Torque-generated, since they are already in a directory called
      torque-generated, and we always refer to them as
      "torque-generated/filename", so there is no confusion even though some
      files now have the same name as a corresponding hand-written file, for
      example factory.cc.
      
      TBR: hpayer@chromium.org
      Bug: v8:7793
      Change-Id: Ie172babad1fc7422fd1059c48f5dafaa53e50c8b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2414218
      Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#70060}
      64caf2b0
  18. 29 May, 2020 1 commit
  19. 26 May, 2020 1 commit
    • Seth Brenith's avatar
      Revert "[torque][cleanup] Use more precise field types in a few classes" · 16cb2d94
      Seth Brenith authored
      This reverts commit 4e5fabae.
      
      Reason for revert: performance regressions chromium:1085305, chromium:1084978
      
      Original change's description:
      > [torque][cleanup] Use more precise field types in a few classes
      > 
      > This change updates some Torque-defined classes to include more precise
      > field types where possible. It also updates those classes to use
      > @generateCppClass. One field was removed because it's unused
      > (PrototypeInfo::validity_cell), and two fields in StackFrameInfo
      > actually became less precise because they're based on Script::name,
      > which is an embedder-provided untyped Local<Value>. (Automatically
      > generated accessors pointed out this bug easily.)
      > 
      > This change also includes a couple of minor fixes in Torque.
      > 
      > Change-Id: Ib2bc6c7165bb3612b6d344c0686a94165a568277
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199640
      > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67907}
      
      TBR=ulan@chromium.org,tebbi@chromium.org,verwaest@chromium.org,seth.brenith@microsoft.com
      
      Change-Id: I720821d8dc84ea0d79eb137f1c2507f75df9a107
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2211322Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67972}
      16cb2d94
  20. 19 May, 2020 1 commit
  21. 13 May, 2020 1 commit
  22. 18 Mar, 2020 1 commit
  23. 20 Feb, 2020 1 commit
  24. 05 Nov, 2019 1 commit
    • Eric Leese's avatar
      V8 Wasm locations should always be based on byte offsets · 5c23e6b5
      Eric Leese authored
      Currently there are two ways wasm locations are represented in the
      inspector. This remains unchanged for now. Also, currently there are
      multiple ways location is represented within V8, with the line number
      sometimes being a function index and sometimes being 0, and the column
      number being a byte offset which is sometimes function relative and
      sometimes module relative. With this change, the line number is never
      used within V8 (it is always 0), and the column number is always a
      byte offset from the beginning of the module. This simplifies
      translation logic and keeps it in one place, and will simplify future
      changes to wasm location representation in the inspector API.
      
      Bug: chromium:1013527
      Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915
      Commit-Queue: Eric Leese <leese@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64774}
      5c23e6b5
  25. 10 Sep, 2019 1 commit
  26. 29 Aug, 2019 1 commit
    • Seth Brenith's avatar
      [cleanup][torque] Use @generateCppClass in some simple cases, part 2 · a5811358
      Seth Brenith authored
      This patch is mostly mechanical. A few changes in
      implementation-visitor.cc might be worth mentioning:
      - Don't generate both field offset macros and class definitions for the
        same class. This was mostly just to keep me from forgetting to remove
        the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but
        also helpfully flagged that FixedArrayBase wasn't using the generated
        class that it requested.
      - Generate forward declarations for all tq-defined classes in
        internal-class-definitions-tq.h. This is helpful for making things
        compile when classes have fields of other class types.
      - When generating accessors for union types, use the nearest class type
        that contains the entire union rather than plain Object. This is
        important for compile-time type safety. It also required a few minor
        fixes elsewhere (isolate.cc, modules.cc, scope-info.cc,
        source-text-module.cc, and a correction of the field types in
        CallHandlerInfo to match how they're set in api.cc).
      
      Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#63458}
      a5811358
  27. 08 Aug, 2019 1 commit
  28. 08 Jul, 2019 1 commit
  29. 04 Jul, 2019 1 commit
    • Simon Zünd's avatar
      [stack-trace] Separate stack-trace symbolization and serialization · db24e200
      Simon Zünd authored
      This CL moves the code responsible for serializing a stack trace frame into
      a string, out of messages.cc and into stack-frame-info.cc. Instead of
      symbolizing the stack trace frame while serializing, the code is changed to
      work on top of StackTraceFrame and StackFrameInfo objects.
      
      The result is that the serialization code no longer cares when a stack trace
      frame is symbolized. Symbolization could happen eagerly during capturing, or
      lazily the first time any of StackFrameInfo fields are accessed.
      
      Drive-by: Existing users of StackFrameBase::ToString are adapted to the
      new SerializeStackTraceFrame API. This includes Isolate::PrintCurrentStackTrace,
      which is changed to re-use the existing capturing and serializing mechanism.
      
      Bug: v8:8742
      Change-Id: Ic7fd80668c9d993e99d586ef7fe022850104c34f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631414
      Commit-Queue: Simon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62522}
      db24e200
  30. 11 Jun, 2019 1 commit
  31. 06 Jun, 2019 1 commit
  32. 23 May, 2019 1 commit
  33. 06 May, 2019 1 commit
  34. 16 Apr, 2019 1 commit
  35. 05 Apr, 2019 1 commit
  36. 01 Mar, 2019 2 commits