1. 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
  2. 15 Apr, 2020 1 commit
  3. 06 Apr, 2020 1 commit
  4. 18 Mar, 2020 1 commit
  5. 18 Feb, 2020 1 commit
    • Seth Brenith's avatar
      Assign CoverageInfo an instance type · 6ce65b96
      Seth Brenith authored
      This allows CoverageInfo to be distinguished from other kinds of
      FixedArray at runtime. I also updated it to use untagged data since it
      only stores ints, since that seems like the generally right thing to do
      (even though I doubt anybody allocates enough of these to notice the
      reduced GC work).
      
      Related Torque changes:
      - Allow structs containing untagged data to be used as class fields.
        This requires classifying them into the tagged or untagged sections of
        the class layout, and checking that their alignment requirements are
        met when stored in a packed array.
      - Generate a struct containing struct field offsets, so we can ensure
        that the layouts defined in Torque and C++ code match. Of course it
        would be nice to generate a lot more (indexed accessors, synchronized
        accessors, GC visitors, etc.), but we can't do it all at once.
      
      Change-Id: I29e2a2afe37e4805cd80e3a84ef9edfe7ca7bb6b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2047399Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#66318}
      6ce65b96
  6. 09 Jan, 2020 1 commit
    • Seth Brenith's avatar
      [cleanup] Don't inherit from Tuple2 and Tuple3 · 24c23947
      Seth Brenith authored
      This change updates CachedTemplateObjectMap, BreakPointInfo, and
      BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3.
      It also removes Tuple3 because nothing else used Tuple3. By avoiding
      tuple types, we get various benefits that Torque can provide:
      - stricter debug verifier functions
      - accessors, cast functions, and printers are generated
      - BreakPoint and BreakPointInfo have different instance types, so you
        can tell them apart at runtime or in a debugger
      
      Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#65668}
      24c23947
  7. 07 Oct, 2019 1 commit
  8. 23 May, 2019 2 commits
  9. 24 Apr, 2019 1 commit
    • Jakob Gruber's avatar
      [coverage] Reduce IncBlockCounter overhead · ae6a47ba
      Jakob Gruber authored
      When collecting JS block coverage, we track block execution counts on
      so-called CoverageInfo objects. Generated bytecode and native code
      contains inlined snippets of code to increment the appropriate
      counters.
      
      These used to be implemented as calls to the IncBlockCounter runtime
      function. Each call incurred the entire CEntry overhead.
      
      This CL reduces that overhead by moving logic over into a new
      IncBlockCounter TFS builtin. The builtin is called directly from
      bytecode, and lowered to the same builtin call for optimized code.
      
      Drive-by: Tweak CoverageInfo layout to generate faster code.
      
      Tbr: jarin@chromium.org
      Bug: v8:9149, v8:6000
      Change-Id: I2d7cb0db649edf7c56b5ef5a4683d27b1c34605c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1571420Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#60981}
      ae6a47ba
  10. 15 Feb, 2019 1 commit
  11. 09 Jan, 2019 1 commit
  12. 18 Dec, 2018 1 commit
  13. 17 Dec, 2018 2 commits
  14. 28 Nov, 2018 1 commit
  15. 27 Nov, 2018 1 commit
  16. 26 Nov, 2018 1 commit
    • Marja Hölttä's avatar
      [iwyu] Include heap-inl.h less. · 0453d418
      Marja Hölttä authored
      - Remove heap-inl.h includes from places where it looked unnecessary. (This is a
        non-scientific approach, because it's probably pulled in indirectly anyway.)
      
      - Annotate places which include heap-inl.h because they need heap/ internals.
      
      - ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.
      
      - Add includes to heap/heap-write-barrier(-inl).h
      
      - A bunch of IWYU fixes discovered when working on this CL (includes which were
        missing because heap-inl.h pulls them in indirectly).
      
      BUG=v8:7490,v8:8238,v8:8499
      
      Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
      Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#57814}
      0453d418
  17. 25 Nov, 2018 1 commit
  18. 24 Nov, 2018 2 commits
  19. 16 Nov, 2018 1 commit
  20. 19 Jul, 2018 1 commit
    • Leszek Swirski's avatar
      [sfi] Remove SFI function identifier field · c941f11a
      Leszek Swirski authored
      Remove the function identifier field from SharedFunctionInfo. This field
      would store one of a) the function's inferred name, b) the "builtin
      function id", or c) debug info. We remove these in turn:
      
      a) The function's inferred name is available on the ScopeInfo, so like
         the start/end position we read it off either the ScopeInfo (for
         compiled functions) or the UncompiledData (for uncompiled functions).
      
         As a side-effect, now both UncompiledData and its subclass,
         UncompiledDataWithPreparsedScope, contain a pointer field. To keep
         BodyDescriptors manageable, we introduce a SubclassBodyDescriptor
         which effectively appends two BodyDescriptors together.
      
      b) The builtin function id is < 255, so we can steal a byte from
         expected no. of properies (also <255) and store these together.
         Eventually we want to get rid of this field and use the builtin ID,
         but this is pending JS builtin removal.
      
         As a side-effect, BuiltinFunctionId becomes an enum class (for better
         storage size guarantees).
      
      c) The debug info can hang off anything (since it stores the field it
         replaces), so we can attach it to the script field instead.
      
      This saves a word on compiled function (uncompiled functions
      unfortunately still have to store it in UncompiledData).
      
      Bug: chromium:818642
      Change-Id: I8b4b3a070f0fe328aafcaeac58842d144d12d996
      Reviewed-on: https://chromium-review.googlesource.com/1138328Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54543}
      c941f11a
  21. 28 Jun, 2018 1 commit
    • Ross McIlroy's avatar
      [sfi] Remove DebugInfo field in SharedFunctionInfo. · c51bcd17
      Ross McIlroy authored
      Merges DebugInfo field into the function_identifier field, storing the function
      identifier in the DebugInfo. Also moves some debugging_hints bits to the SFI flags,
      and others to the DebugInfo. Finally, changes the logic to store debugger patched
      bytecode array on the SFI instead of the DebugInfo, simplifying the logic in the
      InterpreterEntryTrampoline.
      
      BUG=chromium:818642,chromium:783853
      TBR=hpayer@chromium.org
      
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: If440080c0f08fac4fb96f5e18dcc0eb9b86d4821
      Reviewed-on: https://chromium-review.googlesource.com/1115819
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54081}
      c51bcd17
  22. 10 Apr, 2018 1 commit
    • Matheus Marchini's avatar
      interpreter: make interpreted frames distinguishable in the native stack · ada64b58
      Matheus Marchini authored
      Before Turbofan/Ignition it was possible to use external profilers to
      sample running V8/Node.js processes and generate reports/FlameGraphs
      from that. It's still possible to do so, but non-optimized JavaScript
      functions appear in the stack as InterpreterEntryTrampoline. This commit
      adds a runtime flag which makes interpreted frames visible on the
      process' native stack as distinguishable functions, making the sampled
      data gathered by external profilers such as Linux perf and DTrace more
      useful.
      
      R=bmeurer@google.com, franzih@google.com, jarin@google.com, yangguo@google.com
      
      Bug: v8:7155
      Change-Id: I3dc8876aa3cd9f1b9766624842a7cc354ccca415
      Reviewed-on: https://chromium-review.googlesource.com/959081
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52533}
      ada64b58
  23. 26 Feb, 2018 1 commit
  24. 16 Aug, 2017 1 commit
  25. 02 Aug, 2017 1 commit
    • Alexey Kozyatinskiy's avatar
      [inspector] move breakpoint management to native · cd9e86a5
      Alexey Kozyatinskiy authored
      My goal was to move breakpoint API to native with minimal changes around, so on inspector side we use v8::debug::BreakpointId instead of String16, on v8::internal::Debug we use i::BreakPoint object instead of break point object created inside of debug.js.
      
      There are a lot of opportunities how we can improve breakpoints (at least we can avoid some of linear lookups to speedup implementation) but I think that as first step we need to remove mirrors/debug.js APIs.
      
      Drive by: debugger-script.js and usage of debugger context in inspector code base.
      
      R=yangguo@chromium.org,jgruber@chromium.org,clemensh@chromium.org
      
      Bug: v8:5510,chromium:652939
      Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I0b17972c39053dd4989bbe26db2bb0b88ca378f7
      Reviewed-on: https://chromium-review.googlesource.com/593156Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47091}
      cd9e86a5
  26. 06 Jun, 2017 1 commit
    • jgruber's avatar
      [coverage] Block coverage with support for IfStatements · b4241540
      jgruber authored
      This CL implements general infrastructure for block coverage together with
      initial support for if-statements.
      
      Coverage output can be generated in lcov format by d8 as follows:
      
      $ d8 --block-coverage --lcov=$(echo ~/simple-if.lcov) ~/simple-if.js
      $ genhtml ~/simple-if.lcov -o ~/simple-if
      $ chrome ~/simple-if/index.html
      
      A high level overview of the implementation follows:
      
      The parser now collects source ranges unconditionally for relevant AST nodes.
      Memory overhead is very low and this seemed like the cleanest and simplest
      alternative.
      
      Bytecode generation uses these ranges to allocate coverage slots and insert
      IncBlockCounter instructions (e.g. at the beginning of then- and else blocks
      for if-statements). The slot-range mapping is generated here and passed on
      through CompilationInfo, and is later accessible through the
      SharedFunctionInfo.
      
      The IncBlockCounter bytecode fetches the slot-range mapping (called
      CoverageInfo) from the shared function info and simply increments the counter.
      We don't collect native-context-specific counts as they are irrelevant to our
      use-cases.
      
      Coverage information is finally generated on-demand through Coverage::Collect.
      The only current consumer is a d8 front-end with lcov-style output, but the
      short-term goal is to expose this through the inspector protocol.
      
      BUG=v8:6000
      CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_chromium_rel_ng
      
      Review-Url: https://codereview.chromium.org/2882973002
      Cr-Commit-Position: refs/heads/master@{#45737}
      b4241540
  27. 31 May, 2017 1 commit
    • jgruber's avatar
      [debug] Untangle DebugInfo from break point support · d3371c23
      jgruber authored
      DebugInfo was very closely tied to break point support:
      * It contained only information relevant to break points.
      * It was created and freed by break point implementation.
      * Existence of a DebugInfo on the shared function info implied existence of
        break points.
      
      This CL is a step towards making DebugInfo usable by other debugging
      functionality such as block coverage by decoupling it from break point support,
      which is now only one kind of information stored on the DebugInfo object.
      
      BUG=v8:6000
      
      Review-Url: https://codereview.chromium.org/2909893002
      Cr-Commit-Position: refs/heads/master@{#45640}
      d3371c23
  28. 23 May, 2017 1 commit