1. 22 May, 2018 2 commits
  2. 09 Apr, 2018 1 commit
  3. 06 Apr, 2018 2 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored
      This reverts commit f9a2e24b.
      
      Reason for revert: gc stress failures not all fixed by follow up.
      
      Original change's description:
      > [cleanup] Refactor the Factory
      > 
      > There is no good reason to have the meat of most objects' initialization
      > logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      > this CL changes the protocol between Heap and Factory to be AllocateRaw,
      > and all object initialization work after (possibly retried) successful
      > raw allocation happens in the Factory.
      > 
      > This saves about 20KB of binary size on x64.
      > 
      > Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      > Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      > Reviewed-on: https://chromium-review.googlesource.com/959533
      > Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      > Reviewed-by: Hannes Payer <hpayer@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52416}
      
      TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
      
      Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
      Commit-Queue: Michael Achenbach <machenbach@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored
      There is no good reason to have the meat of most objects' initialization
      logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
      this CL changes the protocol between Heap and Factory to be AllocateRaw,
      and all object initialization work after (possibly retried) successful
      raw allocation happens in the Factory.
      
      This saves about 20KB of binary size on x64.
      
      Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
      Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
      Reviewed-on: https://chromium-review.googlesource.com/959533
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  4. 06 Dec, 2017 1 commit
  5. 02 Nov, 2017 1 commit
  6. 26 Oct, 2017 1 commit
  7. 11 Aug, 2017 1 commit
  8. 03 Aug, 2017 2 commits
  9. 02 Aug, 2017 4 commits
  10. 01 Aug, 2017 2 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
  11. 29 May, 2017 1 commit
  12. 27 Jan, 2017 1 commit
  13. 17 Jan, 2017 1 commit
    • jgruber's avatar
      [heap] Don't allocate immovable code in LO space during serialization · 47684fe8
      jgruber authored
      Background: the first page of each space is implicitly immovable.
      Recently, our builtin code objects have reached a size at which we
      fill up the first page of code space during initialization. Once
      that occurs, newly requested allocations of immovable code are
      allocated in a large object space page of 512K.
      
      This CL mitigates these effects by simply marking pages as immovable
      during snapshot creation instead of going into LO space.
      
      On snapshot builds, this should just work: deserialized pages are
      trimmed and marked immovable when deserialization finishes.
      
      However, non-snapshot builds and allocations of immovable CEntryStub
      code at runtime are still affected.
      
      BUG=v8:5831
      
      Review-Url: https://codereview.chromium.org/2635973002
      Cr-Commit-Position: refs/heads/master@{#42411}
      47684fe8
  14. 06 Dec, 2016 1 commit
    • ulan's avatar
      [heap] Ensure finalization of incremental marking even if all allocations · fdc0aa0c
      ulan authored
      come from the runtime.
      
      This patch fixes an issue of heap growing to max capacity when incremental
      marking is finished but cannot finalize due to GC stack guard not triggering.
      
      It can happen if all allocations come from the runtime, for example,
      from JSON parser or compiler.
      
      Now before expanding the heap we check if we are above the allocation limit
      and the incremental marking needs to be finalized. If so we do not expand
      the heap and force GC, which will finalize the incremental marking.
      The check is performed for paged spaces and large-object space.
      
      BUG=chromium:670675
      
      Review-Url: https://codereview.chromium.org/2552613004
      Cr-Commit-Position: refs/heads/master@{#41524}
      fdc0aa0c
  15. 18 Nov, 2016 2 commits
  16. 25 Oct, 2016 1 commit
  17. 28 Sep, 2016 3 commits
  18. 04 Aug, 2016 1 commit
  19. 02 Mar, 2016 1 commit
  20. 25 Feb, 2016 1 commit
  21. 17 Feb, 2016 1 commit
    • ulan's avatar
      Filter invalid slots after array trimming. · 017d128b
      ulan authored
      If sweeping is in progress then we need to filter out slots in free space after
      array trimming, because the sweeper will add the free space into free list.
      
      This CL also fixes a bug in SlotSet::RemoveRange.
      
      BUG=chromium:587004
      LOG=NO
      TBR=hpayer@chromium.org
      
      Review URL: https://codereview.chromium.org/1701963003
      
      Cr-Commit-Position: refs/heads/master@{#34071}
      017d128b
  22. 03 Feb, 2016 2 commits
  23. 02 Feb, 2016 1 commit
  24. 16 Dec, 2015 1 commit
    • mlippautz's avatar
      Reland of "[cctest] Add tests for aborting compaction of pages" · 2bb51df9
      mlippautz authored
      Tests for
      * aborting a full page.
      * partially aborting a page.
      * partially aborting a page with pointers between aborted pages.
      * partially aborting a page with store buffer entries.
      
      Also introduces force_oom() which prohibits a old space to
      expand
      
      BUG=chromium:524425
      LOG=N
      
      CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_nosnap_rel,v8_linux_nosnap_dbg,v8_win_nosnap_shared_rel,v8_win_nosnap_shared_compile_rel
      
      Review URL: https://codereview.chromium.org/1518803005
      
      Cr-Commit-Position: refs/heads/master@{#32899}
      2bb51df9
  25. 11 Dec, 2015 2 commits
  26. 09 Dec, 2015 1 commit
  27. 29 Oct, 2015 1 commit
  28. 21 Oct, 2015 1 commit
    • mlippautz's avatar
      Reland "[heap] Divide available memory upon compaction tasks" · 218c06e8
      mlippautz authored
      This reverts commit a31cef44.
      
      Original message:
      
      [heap] Divide available memory upon compaction tasks
      - Fairly (round-robin) divide available memory upon compaction tasks.
      - Ensure an upper limit (of memory) since dividing is O(n) for n free-space
        nodes.
      - Refill from free lists managed by sweeper once a compaction space becomes
        empty.
      
      Assumption for dividing memory: Memory in the free lists is sparse upon starting
      compaction (which means that only few nodes are available), except for memory
      reducer GCs, which happen in idle time though (so it's less of a problem).
      
      BUG=chromium:524425
      LOG=N
      
      Review URL: https://codereview.chromium.org/1421583002
      
      Cr-Commit-Position: refs/heads/master@{#31443}
      218c06e8