- 12 Sep, 2018 3 commits
-
-
Michael Lippautz authored
- Update those counters from space - Add fast path for move memory Fix: - Introduce proper variants for checked arithmetic on atomics. Previous revert was needed to unblock other reverts. This reverts commit 651bd0de. Bug: chromium:845409 Change-Id: I906ef6c60a589a30a0a632eadb8642735deaf0e4 Tbr: ulan@chromium.org Reviewed-on: https://chromium-review.googlesource.com/1221213Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#55828}
-
Michael Achenbach authored
This reverts commit 9d5ab51f. Reason for revert: Blocks important revert. Also rolling is down since 2 days... so please wait with relanding until rolling is confirmed to be up again. https://chromium-review.googlesource.com/c/v8/v8/+/1219695 Original change's description: > Reland "[heap] Introduce backing store counters on Heap" > > - Update those counters from space > - Add fast path for move memory > > Fix: > - Introduce proper variants for checked arithmetic on atomics. > > This reverts commit 0c62f5b3. > > Bug: chromium:845409 > Change-Id: I98ad1a7c470c7e7b805e087b4ec74e3451344712 > Reviewed-on: https://chromium-review.googlesource.com/1219647 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55815} TBR=ulan@chromium.org,mlippautz@chromium.org Change-Id: Ifb7c6e31f7f105bd11d1497a1061f73d42c05c31 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:845409 Reviewed-on: https://chromium-review.googlesource.com/1221186Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#55816}
-
Michael Lippautz authored
- Update those counters from space - Add fast path for move memory Fix: - Introduce proper variants for checked arithmetic on atomics. This reverts commit 0c62f5b3. Bug: chromium:845409 Change-Id: I98ad1a7c470c7e7b805e087b4ec74e3451344712 Reviewed-on: https://chromium-review.googlesource.com/1219647Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#55815}
-
- 11 Sep, 2018 2 commits
-
-
Deepti Gandluri authored
This reverts commit 9c67143f. Reason for revert: Potential cause of mac gpu failures for the auto roller - https://ci.chromium.org/p/chromium/builders/luci.chromium.try/mac_optional_gpu_tests_rel/9158 Original change's description: > [heap] Introduce backing store counters on Heap > > - Update those counters from space > - Add fast path for move memory > > Bug: chromium:845409 > Change-Id: Icd72e551df2422a635801fb4e31588073f81544e > Reviewed-on: https://chromium-review.googlesource.com/1219707 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#55798} TBR=ulan@chromium.org,mlippautz@chromium.org Change-Id: Iaa0d375d84f1c559a13dea9b9f1b7f6907cbd768 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:845409 Reviewed-on: https://chromium-review.googlesource.com/1220293Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/master@{#55807}
-
Michael Lippautz authored
- Update those counters from space - Add fast path for move memory Bug: chromium:845409 Change-Id: Icd72e551df2422a635801fb4e31588073f81544e Reviewed-on: https://chromium-review.googlesource.com/1219707Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#55798}
-
- 17 Aug, 2018 1 commit
-
-
Ben L. Titzer authored
JSArrays and JSArrayBuffers are very different animals. As such, split the js-array.h header into two parts. R=ulan@chromium.org,mstarzinger@chromium.org Bug: v8:5402 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: I82f987ecea3e2e1ceaf8f8962a2b88165558c57e Reviewed-on: https://chromium-review.googlesource.com/1177760Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Ben Titzer <titzer@chromium.org> Cr-Commit-Position: refs/heads/master@{#55183}
-
- 16 Jul, 2018 1 commit
-
-
Peter Marshall authored
We convert this {ptr, size} pair to an ArrayBuffer::Allocation when we need to free it anyway, so we can get rid of this intermediate step to make things simpler. Change-Id: I6e82949ec02acb5794f4d668afb2313ebdcb9d52 Reviewed-on: https://chromium-review.googlesource.com/1136309 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#54457}
-
- 21 Jun, 2018 2 commits
-
-
Peter Marshall authored
Each local ABT is logically for one page. We passed the space in to the constructor, but this is wrong because the space a page is in can change, e.g. for compaction pages. Instead, pass the page to the local ABT constructor and always get the space from this. To do this we need to push the AllocateLocalTracker() helper and friends down to Page, rather than its superclass MemoryChunk. Unfortunately, we need to keep ReleaseLocalTracker() on MemoryChunk even though only Pages can have local trackers, because we can't do virtual dispatch on MemoryChunk::ReleaseAllocatedMemory() which would allow us to clean up the tracker memory nicely for pages only. We also have to make sure we update external bytes accounting properly when swapping spaces, as in SemiSpace::Swap(). Change-Id: Iff02e41dd12a6b04a57fcc32f9e2b4f049fcbc24 Reviewed-on: https://chromium-review.googlesource.com/1107635 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#53930}
-
Peter Marshall authored
Currently we have to access the unreachable ArrayBuffer object to get the backing store pointer when we want to free it. This means we need the original ArrayBuffer object to stay alive until we collect all of the pointers to free (currently done sequentially after marking). We want to move this step to a background task that does not block GC finishing - to do that we need the backing store pointers so that the original page (where the ArrayBuffers live) can be freed. Change-Id: Ifaf070d777939cb23c46da637a25d75f9c863bd8 Reviewed-on: https://chromium-review.googlesource.com/1102434 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#53915}
-
- 15 May, 2018 1 commit
-
-
Wez authored
ArrayBuffer memory allocated off-heap was previously tracked by a test- only retained_size() field on each LocalArrayBufferTracker. Changes in off-heap ArrayBuffer memory usage are now reported to the Space with which the ArrayBuffer is associated, so that the value is cheaply available to include in e.g. GC limit calculations, via a new getter, ExternalBackingStoreBytes(). Changes to external ArrayBuffer backing-store allocations are tracked in an AtomicNumber associated with each Space, to allow for ArrayBuffers being concurrently moved or freed from multiple Pages in the same Space during sweeps & compactions. Bug: chromium:837583 Change-Id: I8b1b6addd5cd05533d8da55ca813e134bc36e181 Reviewed-on: https://chromium-review.googlesource.com/1052347 Commit-Queue: Wez <wez@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#53192}
-
- 02 May, 2018 1 commit
-
-
Michael Lippautz authored
The tracker needs to maintain the byte length as there is no order guarantee when sweeping pages and the byte length may be a HeapNumber that is stored on a different page. The abstraction for ArrayBuffers is left untouched. We distinguish between the following cases: 1. Regular AB (backing_store and bye_length should be used) 2. AB allocated using kReservation but not part of wasm 3. AB allocated using kReservation and part of wasm In practice, 2. does not exist, but we still maintain "allocation_base" and "allocation_length" which fall back to backing_store and byte_length in this case. The problematic part is that they look like innocent getters on the object but actually refer to different data structures or on-heap objects. Since 2. does not exist, and 3. looks up the bounds in its own tracker, it is fine for ArrayBufferTracker to pass backing_store and tracked byte_length. Bug: v8:7701 Change-Id: Ib89d5fe94fce5cef8e5d8343a5415a3b9ad0deba Reviewed-on: https://chromium-review.googlesource.com/1039385Reviewed-by:
Ben Titzer <titzer@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#52923}
-
- 06 Apr, 2018 1 commit
-
-
Michael Lippautz authored
The byte_length of ArrayBuffers may be a heap number. This length is needed for freeing a buffer during tear down, implying that ArrayBuffers need to be freed before regular space tear down can remove actual pages. Bug: v8:7623 Change-Id: Iab91843e48c50276a2e110915f69cf9e6c24ef8f Reviewed-on: https://chromium-review.googlesource.com/997776 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52426}
-
- 20 Nov, 2017 3 commits
-
-
Peter Marshall authored
Free ArrayBuffer backing stores on a background thread, rather than blocking the main thread after processing. Could potentially cause contention with the array buffer allocator once JS execution resumes. The new ArrayBufferCollector class tracks these dead allocations. Later, the processing of array buffers can happen in parallel. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux64_tsan_rel;master.tryserver.v8:v8_linux64_tsan_concurrent_marking_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel Bug: v8:6992 Change-Id: I2b74f008f79521414374f607ed510f66508af160 Reviewed-on: https://chromium-review.googlesource.com/779182 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#49505}
-
Peter Marshall authored
This reverts commit b6658ade. Reason for revert: Breaks TSAN :( Original change's description: > [heap] Concurrently free ArrayBuffer allocations. > > Free ArrayBuffer backing stores on a background thread, rather than > blocking the main thread after processing. Could potentially cause > contention with the array buffer allocator once JS execution resumes. > > The new ArrayBufferCollector class tracks these dead allocations. > > Later, the processing of array buffers can happen in parallel. > > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng > > Bug: v8:6992 > Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904 > Reviewed-on: https://chromium-review.googlesource.com/739829 > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Hannes Payer <hpayer@chromium.org> > Cr-Commit-Position: refs/heads/master@{#49485} TBR=hpayer@chromium.org,mlippautz@chromium.org,petermarshall@chromium.org Change-Id: If6743b83f871c0fd0d6e83a3083dce0eecd99021 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:6992 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Reviewed-on: https://chromium-review.googlesource.com/779159Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#49488}
-
Peter Marshall authored
Free ArrayBuffer backing stores on a background thread, rather than blocking the main thread after processing. Could potentially cause contention with the array buffer allocator once JS execution resumes. The new ArrayBufferCollector class tracks these dead allocations. Later, the processing of array buffers can happen in parallel. Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng Bug: v8:6992 Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904 Reviewed-on: https://chromium-review.googlesource.com/739829 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#49485}
-
- 24 Oct, 2017 1 commit
-
-
Peter Marshall authored
This speeds up insertion and removal by reducing the time taken to hash. Bug: v8:6992 Change-Id: I4e9e1c97a5503bf5a09c2428980a3c2d6bf4051e Reviewed-on: https://chromium-review.googlesource.com/735419Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#48867}
-
- 11 Oct, 2017 2 commits
-
-
Eric Holk authored
This reverts commit b0ced926. Reason for revert: Build breakage - https://build.chromium.org/p/client.v8/builders/V8%20Linux/builds/20832 Original change's description: > Track committed array buffer size rather than allocation length > > WebAssembly creates ArrayBuffers with large allocations where only a small > amount is committed. The uncommitted address space should not be counted as used > memory. Doing so can lead to the GC spending unnecessary time collecting memory > when there is not really pressure. > > Bug: > Change-Id: Ife7b84e9858e87faabc360a61f887b2fda6d99db > Reviewed-on: https://chromium-review.googlesource.com/710227 > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Eric Holk <eholk@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48462} TBR=mlippautz@chromium.org,eholk@chromium.org Change-Id: Ib7b28a7bbc8ffc11e0bf8c4bb16b2da61cbdbd5f No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/712835Reviewed-by:
Eric Holk <eholk@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48466}
-
Eric Holk authored
WebAssembly creates ArrayBuffers with large allocations where only a small amount is committed. The uncommitted address space should not be counted as used memory. Doing so can lead to the GC spending unnecessary time collecting memory when there is not really pressure. Bug: Change-Id: Ife7b84e9858e87faabc360a61f887b2fda6d99db Reviewed-on: https://chromium-review.googlesource.com/710227Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48462}
-
- 04 Oct, 2017 2 commits
-
-
Eric Holk authored
This reverts commit 5e76ff5a. Reason for revert: tsan failures - https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN/builds/17574 Original change's description: > Reland "[wasm] always allocate memory when guard regions are needed" > > This reverts commit 7cf29d8d. > > Original change's description: > > [wasm] always allocate memory when guard regions are needed > > > > When using trap handlers, memory references do not get any checks inserted. This > > means there is no check for a null memory as happens when the memory size is > > 0. Normally this would be correctly caught as an out of bounds access, since the > > low memory addresses are not normally mapped. However, if they were mapped for > > some reason, we would not catch the out of bounds access. > > > > The fix is to ensure WebAssembly instances always have a guard region even if > > the memory is size 0. > > > > Bug: chromium:769637 > > Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00 > Reviewed-on: https://chromium-review.googlesource.com/695812 > Commit-Queue: Eric Holk <eholk@chromium.org> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/master@{#48293} TBR=gdeepti@chromium.org,mtrofin@chromium.org,mlippautz@chromium.org,eholk@chromium.org,eholk@google.com,clemensh@chromium.org Change-Id: I52d5354126158a92602b08c48703d562ac95075b No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/699599Reviewed-by:
Eric Holk <eholk@chromium.org> Commit-Queue: Eric Holk <eholk@chromium.org> Cr-Commit-Position: refs/heads/master@{#48294}
-
Eric Holk (eholk) authored
This reverts commit 7cf29d8d. Original change's description: > [wasm] always allocate memory when guard regions are needed > > When using trap handlers, memory references do not get any checks inserted. This > means there is no check for a null memory as happens when the memory size is > 0. Normally this would be correctly caught as an out of bounds access, since the > low memory addresses are not normally mapped. However, if they were mapped for > some reason, we would not catch the out of bounds access. > > The fix is to ensure WebAssembly instances always have a guard region even if > the memory is size 0. > > Bug: chromium:769637 Change-Id: I09fdaea92b7ccb3a6cc9e28392171ec098538a00 Reviewed-on: https://chromium-review.googlesource.com/695812 Commit-Queue: Eric Holk <eholk@chromium.org> Reviewed-by:
Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#48293}
-
- 10 Aug, 2017 1 commit
-
-
Ulan Degenbaev authored
This patch merges ObjectMarking and MarkingState. The new marking state encapsulates object marking, live byte tracking, and access atomicity. The old ObjectMarking calls are now replaced with calls to marking state. For example: ObjectMarking::WhiteToGrey<kAtomicity>(obj, marking_state(obj) becomes marking_state()->WhiteToGrey(obj) This simplifies custom handling of live bytes and allows to chose atomicity of markbit accesses depending on collector's state. This also decouples marking bitmap from the marking code, which will allows in future to use different data-structure for mark-bits. Bug: chromium:694255 Change-Id: Ifb4bc0144187bac1c08f6bc74a9d5c618fe77740 Reviewed-on: https://chromium-review.googlesource.com/602132 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#47288}
-
- 31 May, 2017 1 commit
-
-
Michael Lippautz authored
Bug: Change-Id: If4a5408f8ff63a8a2b189f60fda37896a9403d3d Reviewed-on: https://chromium-review.googlesource.com/519386Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#45646}
-
- 30 May, 2017 3 commits
-
-
Michael Lippautz authored
Retrieve length from the buffer instead of storing in as value in the map. This reverts commit a73323d3. Bug: Change-Id: I2f17b1b121380ec3d70f42d7cd0015720d6dc7d1 Reviewed-on: https://chromium-review.googlesource.com/518132Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#45611}
-
Michael Achenbach authored
This reverts commit a402dd63. Reason for revert: Breaks msan: https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/15197 Original change's description: > [heap] Simplify array buffer tracker > > Retrieve length from the buffer instead of storing in as value in the > map. > > Change-Id: Icdc87bb46c29fff779bf6e98139324662ced5bf6 > Reviewed-on: https://chromium-review.googlesource.com/518171 > Commit-Queue: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jochen Eisinger <jochen@chromium.org> > Cr-Commit-Position: refs/heads/master@{#45600} NOTRY=true NOTREECHECKS=true NOPRESUBMIT=true TBR=mlippautz@chromium.org,jochen@chromium.org No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: I22e3590528beb911d366b9d93ec302857a631971 Reviewed-on: https://chromium-review.googlesource.com/518117 Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#45606}
-
Michael Lippautz authored
Retrieve length from the buffer instead of storing in as value in the map. Change-Id: Icdc87bb46c29fff779bf6e98139324662ced5bf6 Reviewed-on: https://chromium-review.googlesource.com/518171 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/master@{#45600}
-
- 09 May, 2017 1 commit
-
-
mlippautz authored
BUG=chromium:651354 Review-Url: https://codereview.chromium.org/2870683003 Cr-Commit-Position: refs/heads/master@{#45184}
-
- 19 Aug, 2016 1 commit
-
-
mlippautz authored
Revert of [heap] Improve size profiling for ArrayBuffer tracking (patchset #6 id:140001 of https://codereview.chromium.org/2210263002/ ) Reason for revert: Tanks octane Original issue's description: > [heap] Improve size profiling for ArrayBuffer tracking > > Eagerly account for retained sizes during ArrayBuffer tracking. Following up on this, > we can now do Scavenges if the amount of memory retained from new space is too large. > > BUG=chromium:621829 > R=jochen@chromium.org,hpayer@chromium.org > > Committed: https://crrev.com/28e13bd6a75c9467dae43043e7b741a1387d5252 > Cr-Commit-Position: refs/heads/master@{#38731} TBR=jochen@chromium.org,hpayer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:621829 Review-Url: https://codereview.chromium.org/2261513003 Cr-Commit-Position: refs/heads/master@{#38739}
-
- 18 Aug, 2016 1 commit
-
-
mlippautz authored
Eagerly account for retained sizes during ArrayBuffer tracking. Following up on this, we can now do Scavenges if the amount of memory retained from new space is too large. BUG=chromium:621829 R=jochen@chromium.org,hpayer@chromium.org Review-Url: https://codereview.chromium.org/2210263002 Cr-Commit-Position: refs/heads/master@{#38731}
-
- 05 Jul, 2016 3 commits
-
-
mlippautz authored
The dependency would only happen if we have a smi overflow for the length and have create a heap number. In this case the heap number would've to survive until the array buffer is collected. To avoid this dependency we track the length (as we previously used to). BUG=chromium:625752 LOG=N TEST=test/mjsunit/regress/regress-625752.js R=hpayer@chromium.org This reverts commit 1791d7bb. Review-Url: https://codereview.chromium.org/2127643002 Cr-Commit-Position: refs/heads/master@{#37537}
-
machenbach authored
Revert of [heap] Track length for array buffers to avoid free-ing dependency (patchset #2 id:20001 of https://codereview.chromium.org/2122603004/ ) Reason for revert: [Sheriff] This makes mjsunit/regress/regress-625752 extremely slow on all gc stress bots and leads to timeouts with custom snapshot: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/6602 Original issue's description: > [heap] Track length for array buffers to avoid free-ing dependency > > The dependency would only happen if we have a smi overflow for the length and > have create a heap number. In this case the heap number would've to survive > until the array buffer is collected. > > To avoid this dependency we track the length (as we previously used to). > > BUG=chromium:625748,chromium:625752 > LOG=N > TEST=test/mjsunit/regress/regress-625752.js > R=hpayer@chromium.org > > Committed: https://crrev.com/ddc75cc1356a58b6cfd63f9da0586e1150496b3d > Cr-Commit-Position: refs/heads/master@{#37530} TBR=hpayer@chromium.org,mlippautz@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:625748,chromium:625752 Review-Url: https://codereview.chromium.org/2127483003 Cr-Commit-Position: refs/heads/master@{#37533}
-
mlippautz authored
The dependency would only happen if we have a smi overflow for the length and have create a heap number. In this case the heap number would've to survive until the array buffer is collected. To avoid this dependency we track the length (as we previously used to). BUG=chromium:625748,chromium:625752 LOG=N TEST=test/mjsunit/regress/regress-625752.js R=hpayer@chromium.org Review-Url: https://codereview.chromium.org/2122603004 Cr-Commit-Position: refs/heads/master@{#37530}
-
- 29 Jun, 2016 2 commits
-
-
mlippautz authored
With the current approach we only need to track using an unordered set as we can still access the backing store pointer and length by the time we free the backing store. Reland: The issue was fixed in 67b5a501. BUG=chromium:619491, chromium:611688 LOG=N R=ulan@chromium.org This reverts commit 0e1eaec7. Review-Url: https://codereview.chromium.org/2109913003 Cr-Commit-Position: refs/heads/master@{#37399}
-
mlippautz authored
Revert of [heap] Optimize ArrayBuffer tracking (patchset #5 id:80001 of https://codereview.chromium.org/2107443002/ ) Reason for revert: Seems to break GPU bots Original issue's description: > [heap] Optimize ArrayBuffer tracking > > With the current approach we only need to track using an unordered set as we can > still access the backing store pointer and length by the time we free the > backing store. > > BUG=chromium:619491, chromium:611688 > LOG=N > R=ulan@chromium.org > > Committed: https://crrev.com/8d2ae27808f047ca8b8f90e63a9c8735321d2ad0 > Cr-Commit-Position: refs/heads/master@{#37318} TBR=ulan@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:619491, chromium:611688 Review-Url: https://codereview.chromium.org/2105273002 Cr-Commit-Position: refs/heads/master@{#37358}
-
- 28 Jun, 2016 1 commit
-
-
mlippautz authored
With the current approach we only need to track using an unordered set as we can still access the backing store pointer and length by the time we free the backing store. BUG=chromium:619491, chromium:611688 LOG=N R=ulan@chromium.org Review-Url: https://codereview.chromium.org/2107443002 Cr-Commit-Position: refs/heads/master@{#37318}
-
- 27 Jun, 2016 1 commit
-
-
mlippautz authored
BUG=chromium:611688 LOG=N R=machenbach@chromium.org Review-Url: https://codereview.chromium.org/2098443002 Cr-Commit-Position: refs/heads/master@{#37271}
-
- 15 Jun, 2016 1 commit
-
-
mlippautz authored
BUG=chromium:619491,chromium:611688 LOG=N R=ulan@chromium.org Review-Url: https://codereview.chromium.org/2065013002 Cr-Commit-Position: refs/heads/master@{#37010}
-
- 07 Jun, 2016 1 commit
-
-
mlippautz authored
backing store. Details of tracking: - Scavenge: New space pages are processes in bulk on the main thread - MC: Unswept pages are processed in bulk in parallel. All other pages are processed by the sweeper concurrently. BUG=chromium:611688 LOG=N TEST=cctest/test-array-buffer-tracker/* CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_tsan_rel,v8_mac64_asan_rel Review-Url: https://codereview.chromium.org/2036643002 Cr-Commit-Position: refs/heads/master@{#36798}
-
- 02 Jun, 2016 1 commit
-
-
mlippautz authored
Revert of Reland "[heap] Fine-grained JSArrayBuffer tracking" (patchset #7 id:180001 of https://codereview.chromium.org/2026633003/ ) Reason for revert: Also failing with the new implementation: https://build.chromium.org/p/chromium.gpu/builders/Linux%20Debug%20%28NVIDIA%29/builds/62646 Will do a local repro now. Original issue's description: > Track based on JSArrayBuffer addresses on pages instead of the attached > backing store. > > Details of tracking: > - Scavenge: New space pages are processes in bulk on the main thread > - MC: Unswept pages are processed in bulk in parallel. All other pages > are processed by the sweeper concurrently. > > BUG=chromium:611688 > LOG=N > TEST=cctest/test-array-buffer-tracker/* > CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_tsan_rel,v8_mac64_asan_rel > > Committed: https://crrev.com/279e274eccf95fbb4bd41d908b9153acf6ec118a > Cr-Commit-Position: refs/heads/master@{#36653} TBR=hpayer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:611688 Review-Url: https://codereview.chromium.org/2032973002 Cr-Commit-Position: refs/heads/master@{#36663}
-
- 01 Jun, 2016 1 commit
-
-
mlippautz authored
backing store. Details of tracking: - Scavenge: New space pages are processes in bulk on the main thread - MC: Unswept pages are processed in bulk in parallel. All other pages are processed by the sweeper concurrently. BUG=chromium:611688 LOG=N TEST=cctest/test-array-buffer-tracker/* CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_tsan_rel,v8_mac64_asan_rel Review-Url: https://codereview.chromium.org/2026633003 Cr-Commit-Position: refs/heads/master@{#36653}
-
- 31 May, 2016 1 commit
-
-
mlippautz authored
Revert of Reland "[heap] Fine-grained JSArrayBuffer tracking" (patchset #2 id:20001 of https://codereview.chromium.org/2024063002/ ) Reason for revert: Breaking http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20avx2/builds/7972 Original issue's description: > Track based on JSArrayBuffer addresses on pages instead of the attached > backing store. > > Details of tracking: > - Scavenge: New space pages are processes in bulk on the main thread > - MC: Unswept pages are processed in bulk in parallel. All other pages > are processed by the sweeper concurrently. > > BUG=chromium:611688 > LOG=N > TEST=cctest/test-array-buffer-tracker/* > CQ_EXTRA_TRYBOTS=tryserver.v8:v8_linux_arm64_gc_stress_dbg,v8_linux_gc_stress_dbg,v8_mac_gc_stress_dbg,v8_linux64_tsan_rel,v8_mac64_asan_rel > > Committed: https://crrev.com/089da007bb990b5b29aab257aa836fdd3f3b8ce0 > Cr-Commit-Position: refs/heads/master@{#36608} TBR=hpayer@chromium.org # Skipping CQ checks because original CL landed less than 1 days ago. NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=chromium:611688 Review-Url: https://codereview.chromium.org/2028503003 Cr-Commit-Position: refs/heads/master@{#36609}
-