1. 09 Jul, 2018 1 commit
    • Sigurd Schneider's avatar
      [turbofan] Use relative calls/jumps on arm for builtins · 23dbb81d
      Sigurd Schneider authored
      This CL uses pc-relative jumps and calls (B/BL) for calls from embedded
      builtins to embedded builtins. To make this work, the code range size is
      limited to 32MB on arm during mksnapshot, which ensures that all builtin
      to builtin offsets for jumps/calls fit into the B/BL immediate. At code
      generation time, we put a placeholder into the instruction offset which
      we resolve to the right code object when the code is copied to the heap.
      We use a new relocation mode RELATIVE_CODE_TARGET for these relative jumps.
      The relocation mode RELATIVE_CODE_TARGET should never appear after
      generating the snapshot.
      
      We modify the target_address/set_target_address methods of RelocInfo
      such that they return the absolute target addresses for pc-relative B/BL
      instructions. This ensures that the GC can treat RELATIVE_CODE_TARGET in
      the same way as code targets. This, however, only matters during
      snapshot creation time, and production code never contains
      RELATIVE_CODE_TARGET relocations.
      
      Bug: v8:6666
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
      Change-Id: If7eab83ad588859ca87c654a5ddc3e37caea884c
      Reviewed-on: https://chromium-review.googlesource.com/1117181Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#54320}
      23dbb81d
  2. 01 Jun, 2018 1 commit
  3. 08 May, 2018 1 commit
  4. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  5. 05 Apr, 2018 1 commit
    • jgruber's avatar
      Rename Code::instruction_{start,end,size} functions · 7b29fe43
      jgruber authored
      In order to clarify the difference between, e.g., InstructionStart and
      instruction_start, rename as follows:
      
      Code::instruction_start -> raw_instruction_start
      Code::instruction_end   -> raw_instruction_end
      Code::instruction_size  -> raw_instruction_size
      
      The difference between the camel-case and raw_* function families is
      in how they handle off-heap-trampoline Code objects. For example, when
      called on an off-heap-trampoline: raw_instruction_start returns the
      trampoline's entry point, while InstructionStart returns the off-heap
      code's entry point (located in the .text section of the binary).
      
      Some callsites were updated to call the camel-case function family as
      appropriate.
      
      Bug: v8:6666
      Change-Id: I4a572f47c2d161a853599d7c17879e263b0d1a87
      Reviewed-on: https://chromium-review.googlesource.com/997532
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52387}
      7b29fe43
  6. 21 Mar, 2018 1 commit
  7. 05 Mar, 2018 3 commits
  8. 13 Feb, 2018 1 commit
  9. 02 Feb, 2018 1 commit
  10. 13 Oct, 2017 1 commit
  11. 15 Sep, 2017 1 commit
    • Ulan Degenbaev's avatar
      [heap] Fix memory leak in the remembered set. · 163d3604
      Ulan Degenbaev authored
      Empty slot set buckets can leak in the following scenarios.
      
      Scenario 1 (large object space):
      1) A large array is allocated in the large object space.
      2) The array is filled with old->new references, which allocates new
         slot set buckets.
      3) The references are overwritten with smis or old space pointers, which
         make the slots set buckets empty.
      4) Garbage collection (scavenge or mark-compact) iterates the slots set
         of the array and pre-frees the empty buckets.
      5) Steps 2-4 repeated many times and leak arbitary many empty buckets.
      The fix to free empty buckets for large object space in mark-compact. 
      
      Scenario 2 (no mark-compact):
      1) A small array is allocated in the old space.
      2) The array is filled with old->new references, which allocates new
         slot set buckets.
      3) The references are overwritten with smis or old space pointers, which
         make the slots set buckets empty.
      4) Scavenge iterates the slots set of the array and pre-frees the empty
         buckets.
      5) Steps 2-4 repeated many times and leak arbitary many empty buckets.
      The fix to free empty buckets for swept pages in scavenger.
      
      Bug: v8:6800
      TBR: mlippautz@chromium.org
      Change-Id: I48d94870f5acf4f6208858271886911c895a9126
      Reviewed-on: https://chromium-review.googlesource.com/668442Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48041}
      163d3604
  12. 16 Aug, 2017 1 commit
  13. 04 Aug, 2017 1 commit
  14. 03 Aug, 2017 1 commit
  15. 02 Aug, 2017 4 commits
  16. 01 Aug, 2017 3 commits
    • Ulan Degenbaev's avatar
      Revert "[heap] Add mechanism for tracking invalidated slots per memory chunk." · c59b81d7
      Ulan Degenbaev authored
      This reverts commit 7a5a777c.
      
      Reason for revert: crashing in test-api
      
      Original change's description:
      > [heap] Add mechanism for tracking invalidated slots per memory chunk.
      > 
      > For correct slots recording in concurrent marker, we need to resolve
      > the race that happens when
      > 1) the mutator is invalidating slots for double unboxing or string
      > conversions
      > 2) and the concurrent marker is recording these slots.
      > 
      > This patch adds a data-structure for tracking the invalidated objects.
      > Thus we can allow the concurrent marker to record slots without
      > worrying about clearing them. During old-to-old pointer updating phase
      > we re-check all slots that belong to the invalidated objects.
      > 
      > BUG=chromium:694255
      > 
      > Change-Id: Ifc3d82918cd3b96e5a5fb7125691626a56f4ab83
      > Reviewed-on: https://chromium-review.googlesource.com/591810
      > Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
      > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#47049}
      
      TBR=ulan@chromium.org,mlippautz@chromium.org
      
      Change-Id: I7f4f8e8cb027b921a82e9c0a0623536af02581fb
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:694255
      Reviewed-on: https://chromium-review.googlesource.com/595994Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47052}
      c59b81d7
    • Ulan Degenbaev's avatar
      [heap] Add mechanism for tracking invalidated slots per memory chunk. · 7a5a777c
      Ulan Degenbaev authored
      For correct slots recording in concurrent marker, we need to resolve
      the race that happens when
      1) the mutator is invalidating slots for double unboxing or string
      conversions
      2) and the concurrent marker is recording these slots.
      
      This patch adds a data-structure for tracking the invalidated objects.
      Thus we can allow the concurrent marker to record slots without
      worrying about clearing them. During old-to-old pointer updating phase
      we re-check all slots that belong to the invalidated objects.
      
      BUG=chromium:694255
      
      Change-Id: Ifc3d82918cd3b96e5a5fb7125691626a56f4ab83
      Reviewed-on: https://chromium-review.googlesource.com/591810Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47049}
      7a5a777c
    • Yang Guo's avatar
      Remove cell visiting in object visitor. · 809c3d45
      Yang Guo authored
      Change-Id: Ida5c537fa94a376a134e60edce889b96b676a8f9
      Reviewed-on: https://chromium-review.googlesource.com/584874Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Commit-Queue: Yang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47039}
      809c3d45
  17. 18 Jul, 2017 1 commit
  18. 19 Jun, 2017 1 commit
  19. 22 May, 2017 1 commit
  20. 18 Apr, 2017 1 commit
  21. 31 Mar, 2017 1 commit
  22. 30 Mar, 2017 1 commit
  23. 29 Mar, 2017 1 commit
  24. 24 Mar, 2017 1 commit
  25. 20 Mar, 2017 1 commit
  26. 17 Mar, 2017 1 commit
    • neis's avatar
      Disentangle assembler from isolate. · 94b088ca
      neis authored
      This is a first step towards moving Turbofan code generation off the main thread.
      
      Summary of the changes:
      - AssemblerBase no longer has a pointer to the isolate. Instead, its
        constructor receives the few things that it needs from the isolate (on most
        architectures this is just the serializer_enabled flag).
      - RelocInfo no longer has a pointer to the isolate. Instead, the functions
        that need it take it as an argument.  (There are currently still a few that
        implicitly access the isolate through a HeapObject.)
      - The MacroAssembler now explicitly holds a pointer to the isolate (before, it
        used to get it from the Assembler).
      - The jit_cookie also moved from AssemblerBase to the MacroAssemblers, since
        it's not used at all in the Assemblers.
      - A few architectures implemented parts of the Assembler with the help
        of a Codepatcher that is based on MacroAssembler.  Since the Assembler no
        longer has the isolate, but the MacroAssembler still needs it, this doesn't
        work anymore.  Instead, these Assemblers now use a new PatchingAssembler.
      
      BUG=v8:6048
      
      Review-Url: https://codereview.chromium.org/2732273003
      Cr-Commit-Position: refs/heads/master@{#43890}
      94b088ca
  27. 08 Mar, 2017 1 commit
  28. 07 Mar, 2017 1 commit
  29. 13 Dec, 2016 1 commit
  30. 28 Nov, 2016 1 commit
  31. 18 Oct, 2016 1 commit
  32. 14 Oct, 2016 1 commit
  33. 13 Oct, 2016 1 commit