- 10 Dec, 2021 1 commit
-
-
Dominik Inführ authored
During a shared GC we need to iterate the twice: for marking and later when updating pointers after evacuation. This CL introduces a new remembered set to avoid the second heap iteration, the remembered set is created when iterating the client heaps for marking. When updating pointers, the GC only needs to visit slots in the remembered set. CLIENT_TO_SHARED is only used during GC atm. Bug: v8:11708 Change-Id: Ie7482babb53b5f6ca2115daafe6f208acae98d6e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3315443Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78332}
-
- 19 Aug, 2021 1 commit
-
-
Michael Lippautz authored
HAS_PROGRESS_BAR is set after page initialization at which point all flags are assumed to be immutable while a GC is running. Separating out the progress bar from flags allows setting it lazily at allocation time. Bug: v8:11915 Change-Id: I48a877e0e80d583d7a0fadef2546fc70417806e7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3085268 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/main@{#76382}
-
- 20 Jul, 2021 1 commit
-
-
Igor Sheludko authored
... which will update both the CodeObjectSlot contents and the cached value of the code entry point when the pointed Code object is evacuated. This is done by introducing an OLD_TO_CODE remembered set which is populated with the recorded slots containing pointers to Code objects. CodeDataContainer is the only kind of holder that can contain Code pointers, so having a CodeObjectSlot is enough to compute the holder CodeDataContainer object and update the cached code entry point there. This CL fixes the data race in the previous implementation which were updating the code entry point during Code object migration. Bug: v8:11880 Change-Id: I44aa46af4bad7eb4eaa922b6876d5f2f836e0791 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035084 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#75826}
-
- 16 Oct, 2020 1 commit
-
-
Pierre Langlois authored
Executable V8 pages include 3 reserved OS pages: one for the writable header and two as guards. On systems with 64k OS pages, the amount of allocatable space left for objects can then be quite smaller than the page size, only 64k for each 256k page. This means regular code objects cannot be larger than 64k, while the maximum regular object size is fixed to 128k, half of the page size. As a result code object never reach this limit and we can end up filling regular pages with few large code objects. To fix this, we change the maximum code object size to be runtime value, set to half of the allocatable space per page. On systems with 64k OS pages, the limit will be 32k. Alternatively, we could increase the V8 page size to 512k on Arm64 linux so we wouldn't waste code space. However, systems with 4k OS pages are more common, and those with 64k pages tend to have more memory available so we should be able to live with it. Bug: v8:10808 Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#70569}
-
- 31 Aug, 2020 1 commit
-
-
Jake Hughes authored
With conservative stack scanning enabled, a snapshot of the call stack upon entry to GC will be used to determine part of the root-set. When the collector walks the stack, it looks at each value and determines whether it could be a potential on-heap object pointer. However, unlike with Handles, these on-stack pointers aren't guaranteed to point to the start of the object: the compiler may decide hide these pointers, and create interior pointers in C++ frames which the GC doesn't know about. The solution to this is to include an object start bitmap in the header of each page. Each bit in the bitmap represents a word in the page payload which is set when an object is allocated. This means that when the collector finds an arbitrary potential pointer into the page, it can walk backwards through the bitmap until it finds the relevant object's base pointer. To prevent the bitmap becoming stale after compaction, it is rebuilt during object sweeping. This is experimental, and currently only works with inline allocation disabled, and single generational collection. Bug: v8:10614 Change-Id: I28ebd9562f58f335f8b3c2d1189cdf39feaa1f52 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2375195 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/master@{#69615}
-
- 12 Aug, 2020 1 commit
-
-
Dominik Inführ authored
ArrayBufferTracker was superseded by ArrayBufferList and ArrayBufferSweeper. Now that ArrayBufferSweeper is used in production, we can remove the unused ArrayBufferTracker mechanism. Bug: v8:10064 Change-Id: I479169c76b6c5c634672024f77e689bb64a36504 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339105Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#69351}
-
- 10 Jul, 2020 1 commit
-
-
Ulan Degenbaev authored
Instead allocating the bitmap with malloc, we now reserve a block at the start of the memory chunk. This CL is a partial revert of https://chromium-review.googlesource.com/c/v8/v8/+/1254125 Additionally it refactors field offset computation and moves them to MemoryChunkLayout. Having the bitmap in the memory chunk simplifies sharing of RO pages and also solves the malloc fragmentation issues. Bug: chromium:1073140 Change-Id: Ibc04f48921fc9496370858ce4c25c56b31c93c89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2289979 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#68783}
-