1. 17 Feb, 2020 2 commits
  2. 12 Feb, 2020 2 commits
  3. 11 Feb, 2020 1 commit
  4. 06 Feb, 2020 1 commit
    • Steve Blackburn's avatar
      Serialization without heap assumptions. · 1d2c043a
      Steve Blackburn authored
      Currently back references to regular objects are encoded in terms of
      a relative address, index by chunk index and chunk offset.   This
      approach has the advantage of avoiding the need for a table of
      back-references at deserialization time, but makes strong assumptions
      about the way objects are organized in memory (for example, this will
      not work if the allocator uses a free list rather than a bump pointer).
      
      I did some quick measurements and found that the absolute number of
      objects and back-references is low, suggesting that simply indexing
      objects would work with little (or no) observable impact on peak
      memory use during deserialization.   Indexing only back referenced
      objects is not implemented in this simple CL, but could fairly easily
      be added.
      
      Given that the existing mechanism will remain in place, I have
      implemented the object index by simply making chunk size one, so
      every object lives on its own chunk (with offset zero).   This is
      the moral equivalent to indexing each object but is a more minimal
      change.  Directly encoding an object index will be more efficient,
      the trade off made here is just to keep the change absolutely minimal.
      
      If using an object index becomes the default, this can be optimized
      first by only using an index for each object that is actually back-
      referenced (about half of all objects in my measurements), and more
      aggressively, a technique like register allocation could be used at
      serialization time to limit the number of indices to the maximum
      number of outstanding back-references at any time (basically a live-
      range analysis of back-references).
      
      Bug: v8:9533
      Change-Id: I1b7ae87e954f67f6405c2bbdf3b4a4f385af8579
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030742
      Commit-Queue: Steve Blackburn <steveblackburn@google.com>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66154}
      1d2c043a
  5. 05 Feb, 2020 1 commit
  6. 04 Feb, 2020 1 commit
  7. 30 Jan, 2020 1 commit
  8. 27 Jan, 2020 2 commits
  9. 23 Jan, 2020 1 commit
  10. 13 Jan, 2020 1 commit
    • Dominik Inführ's avatar
      [objects] Add ArrayBufferExtension class · 69fda08a
      Dominik Inführ authored
      This CL adds the ArrayBufferExtension class, which is used to track
      JSArrayBuffers in a linked list. The ArrayBufferExtension is going to
      replace the ArrayBufferTracker in the future but is currently behind
      the v8_enable_array_buffer_extension feature flag.
      
      When enabled, each JSArrayBuffer has a corresponding native-heap
      allocated ArrayBufferExtension object. All extensions are currently
      tracked in a single linked list. During marking the GC not only
      marks the JSArrayBuffer but also its extension object. At the end of
      mark-compact the GC iterates all extensions and removes unmarked ones.
      
      Change-Id: I88298be255944d5ae1327c91b0d7f0fdbcd486d5
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1969791Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65724}
      69fda08a
  11. 07 Jan, 2020 1 commit
  12. 02 Jan, 2020 1 commit
  13. 19 Dec, 2019 2 commits
  14. 17 Dec, 2019 1 commit
  15. 13 Dec, 2019 2 commits
  16. 06 Dec, 2019 1 commit
  17. 25 Nov, 2019 2 commits
  18. 22 Nov, 2019 1 commit
  19. 19 Nov, 2019 1 commit
  20. 15 Nov, 2019 2 commits
  21. 07 Nov, 2019 1 commit
    • Matheus Marchini's avatar
      snapshot: add size info for builtins on Posix · 48d964af
      Matheus Marchini authored
      Lack of size information can cause debugging and observability tools to
      misbehave or to fail. We can see the size for all builtins is zero with
      objdump:
      
        $ objdump -t d8 | grep Builtins_ArgumentsAdaptorTrampoline
        0000000001084a00 l     F .text  0000000000000000              Builtins_ArgumentsAdaptorTrampoline
                                        ^
                                        Size is zero
      
      Tools like bpftrace rely on the function size to guarantee a tracepoint
      is added within function boundaries. Without size information, those
      tools can't guarantee a tracepoint will be added safely.
      
      Add .size directive for each builtin function, as described in
      https://sourceware.org/binutils/docs-2.24/as/Size.html#Size, to fix this
      issue. We can see with objdump that the size is properly set:
      
        $ objdump -t d8 | grep Builtins_ArgumentsAdaptorTrampoline
        00000000010bf820 l     F .text  0000000000000140              Builtins_ArgumentsAdaptorTrampoline
      
      R=bmeurer@chromium.org, hpayer@chromium.org, verwaest@chromium.org, yangguo@chromium.org
      
      Change-Id: I4cd2b0a12b629498dd9d7465cc1002dda37028c7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1898807
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64824}
      48d964af
  22. 06 Nov, 2019 1 commit
  23. 05 Nov, 2019 1 commit
  24. 04 Nov, 2019 1 commit
    • Dan Elphick's avatar
      Reland "Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE" · 352bbb12
      Dan Elphick authored
      This is a reland of 855591a5
      
      Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
      Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.
      
      Original change's description:
      > Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      >
      > Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
      >
      > [builtins] Move non-JS linkage builtins code objects into RO_SPACE
      >
      > Creates an allow-list of builtins that can still go in code_space
      > including all TFJ builtins and a small manual list that should be pared
      > down in the future.
      >
      > For builtins that go in RO_SPACE a Code object is created that contains an
      > immediate trap instruction. Generally these Code objects are still no
      > smaller than CODE_SPACE Code objects because of the Code object alignment
      > requirements. This will hopefully be addressed in a follow-up CL either by
      > relaxing them or removing the instruction stream completely.
      >
      > In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
      > increases by the same amount.
      >
      > Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
      > Commit-Queue: Dan Elphick <delphick@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64700}
      
      Change-Id: I4eeb7dab3027b42fa58c5dfb2bad9873e9fff250
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893192
      Commit-Queue: Dan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64728}
      352bbb12
  25. 31 Oct, 2019 2 commits
  26. 28 Oct, 2019 3 commits
    • Seth Brenith's avatar
      [torque] Use generated instance types, part 1 · 91e6421c
      Seth Brenith authored
      This change begins making use of the fact that Torque now knows about
      the relationship between classes and instance types, to replace a few
      repetitive lists:
      
      - Instance type checkers (single and range), defined in
        src/objects/instance-type.h
      - Verification dispatch in src/diagnostics/objects-debug.cc
      - Printer dispatch in src/diagnostics/objects-printer.cc
      - Postmortem object type detection in
        tools/debug_helper/get-object-properties.cc
      
      Torque is updated to generate four macro lists for the instance types,
      representing all of the classes separated in two dimensions: classes
      that correspond to a single instance type versus those that have a
      range, and classes that are fully defined in Torque (with fields and
      methods inside '{}') versus those that are only declared. The latter
      distinction is useful because fully-defined classes are guaranteed to
      correspond to real C++ classes, whereas only-declared classes are not.
      
      A few other changes were required to make the lists above work:
      
      - Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
        and avoid conflicts with the new macro-generated IsFiller method. This
        is the part I'm most worried about: I think the new name is an
        improvement for clarity and consistency, but I could imagine someone
        typing IsFiller out of habit and introducing a bug. If we'd prefer to
        keep the name IsFiller, my other idea is to rename FreeSpace to
        VariableSizeFiller and Filler to FixedSizeFiller.
      - Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
        expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
      - Normalized the dispatched behavior for BigIntBase and HeapNumber.
      - Added a few new object printers.
      
      Bug: v8:7793
      Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Reviewed-by: 's avatarDan Elphick <delphick@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64597}
      91e6421c
    • Michael Starzinger's avatar
      [turbofan][ia32] Remove call to code object via slot. · 572be6f1
      Michael Starzinger authored
      R=jgruber@chromium.org
      BUG=v8:6666,v8:9810
      
      Change-Id: I972983d8e86729843f4a1bbe050e3b37a3c0c61c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1881147Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64578}
      572be6f1
    • Jakob Gruber's avatar
      [builtins] Don't emit debug infos in release builds · 28e0e97d
      Jakob Gruber authored
      Debug infos for embedded builtins (associating a file and line number
      with certain code ranges) should only be emitted in debug modes.
      
      This CL disables source position emission in Torque in release builds,
      and adds checks that the external filename / source position lists are
      empty in release builds.
      
      Bug: v8:9910
      Change-Id: Ic69683a2324c3b334150ee2b7da9972fbee56483
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1879903Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64576}
      28e0e97d
  27. 25 Oct, 2019 1 commit
    • Leszek Swirski's avatar
      [heap] Add base class for LargeObjectSpaces · eb667651
      Leszek Swirski authored
      Both LO_SPACE and NEW_LO_SPACE use the basic page management system of
      LargeObjectSpace, but implement different AllocateRaw methods (with
      the NEW_LO_SPACE version shadowing the LO_SPACE version).
      
      To clean this up, and allow other future LargeObjectSpace implementations
      (in particular, an off-thread variant), refactored the current
      LargeObjectSpace into a base class, and make both LargeObjectSpace
      (renamed to OldLargeObjectSpace) and NewLargeObjectSpace extend this
      class.
      
      Bug: chromium:1011762
      Change-Id: I41b45b97f2611611dcfde677213131396df03a5e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1876824
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Auto-Submit: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64560}
      eb667651
  28. 22 Oct, 2019 2 commits
  29. 21 Oct, 2019 1 commit
    • Seth Brenith's avatar
      Fix JSEntry unwinding data on Windows ARM64 · cdf8925e
      Seth Brenith authored
      The current unwinding data for JSEntry correctly restores the frame
      pointer and program counter from the caller frame, which might or might
      not be sufficient to continue unwinding, depending on the contents of
      that caller frame. Currently, the cctest StackUnwindingWin64 is broken
      (at least with my build config) because the caller frame also needs the
      stack pointer, which is not restored correctly.
      
      In particular, I see this xdata for v8::internal::GeneratedCode<...>,
      which is the function that calls Builtins_JSEntry:
      
      10400015 : 2 code words, 1 epilog, function length=15
      01000012 : epilog starts at 12 and its unwind handler starts at 4
      e405c8d2 : save_reg x=b z=8
                 alloc_s x=5
                 end
      e405c8d2 : same thing but for the epilog
      
      The prolog that corresponds to the unwind codes above is:
      
      sub sp, sp, #50
      str lr, [sp, #0x40]
      
      Note that it does not set fp, so unwinding requires an accurate sp.
      
      This change emits slightly more complicated unwinding data for JSEntry
      so that the frame pointer, stack pointer, and program counter can all be
      restored.
      
      Change-Id: I0c7f3eba97ef64408f46631b487c4b0ceb06fa9b
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1848860
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64435}
      cdf8925e