- 07 Jul, 2022 1 commit
-
-
Manos Koukoutos authored
Mostly src/codegen, src/compiler, src/snapshot, src/utils. Bug: v8:13006 Change-Id: I2fb31acc749a7376e6f2a7424ed2e67ff479d971 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3749178 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81575}
-
- 09 Jun, 2022 1 commit
-
-
Igor Sheludko authored
... which required unnecessarily big alignment for the base on Windows. Drive-by: adapt hint usage in VirtualMemoryCage::InitReservation() for non-zero kReservedCodeRangePages and hint values provided by CodeRangeAddressHint::GetAddressHint() which might be the start address of the previously reserved region which in turn already includes the kReservedCodeRangePages pages. Bug: v8:11880, v8:12942 Change-Id: Ieee44ed2bdfc77aa8efaef449221caaae1f0f08f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695382Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#81026}
-
- 13 May, 2022 1 commit
-
-
Samuel Groß authored
This is more consistent with similar features, for example V8_ENABLE_WEBASSEMBLY or V8_ENABLE_MAGLEV. Drive-by: remove V8_SANDBOX_IS_AVAILABLE as it's no longer needed. Bug: v8:10391 Change-Id: I8658c5b0c331a4c73892737083b2c2f9b8f84056 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647355 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Samuel Groß <saelo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#80530}
-
- 28 Apr, 2022 1 commit
-
-
Igor Sheludko authored
This is a reland of commit 9d31f866 There were issues with --future flag implications on M1. Original change's description: > [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1) > > ... for V8 code space. The feature is currently disabled. > > In order to use fast W^X permission switching we must allocate > executable pages with readable writable executable permissions (RWX). > However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further > permission changing of RWX memory pages. This means that the code page > headers must be allocated with RWX permissions too because otherwise > it wouldn't be possible to allocate a large code page over the freed > regular code page and vice versa. > > When enabled, the new machinery works as follows: > > 1) when memory region is reserved for allocating executable pages, the > whole region is committed with RWX permissions and then decommitted, > 2) since reconfiguration of RWX page permissions is not allowed on > MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts > to change them, > 3) the request to set RWX permissions in the executable page region > just recommits the pages without changing permissions (see (1), they > were already allocated as RWX and then discarded), > 4) in order to make executable pages inaccessible one must use > OS::DiscardSystemPages() instead of OS::DecommitPages() or > setting permissions to kNoAccess because the latter two are not > allowed by the MacOS (see (2)). > 5) since code space page headers are allocated as RWX pages it's also > necessary to switch between W^X modes when updating the data in the > page headers (i.e. when marking, updating stats, wiring pages in > lists, etc.). The new CodePageHeaderModificationScope class is used > in the respective places. On unrelated configurations it's a no-op. > > The fast permission switching can't be used for V8 configuration with > enabled pointer compression and disabled external code space because > a) the pointer compression cage has to be reserved with MAP_JIT flag > which is too expensive, > b) in case of shared pointer compression cage if the code range will > be deleted while the cage is still alive then attempt to configure > permissions of pages that were previously set to RWX will fail. > > This also CL extends the unmapper unit tests with permissions tracking > for discarded pages. > > Bug: v8:12797 > Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80238} Bug: v8:12797 Change-Id: I0fe86666f31bad37d7074e217555c95900d2afba Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610433Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80259}
-
- 27 Apr, 2022 2 commits
-
-
Adam Klein authored
This reverts commit 9d31f866. Reason for revert: crashes on Mac/arm64 bots: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug/5923/overview Original change's description: > [rwx][mac] Support fast W^X permission switching on Apple Silicon (M1) > > ... for V8 code space. The feature is currently disabled. > > In order to use fast W^X permission switching we must allocate > executable pages with readable writable executable permissions (RWX). > However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further > permission changing of RWX memory pages. This means that the code page > headers must be allocated with RWX permissions too because otherwise > it wouldn't be possible to allocate a large code page over the freed > regular code page and vice versa. > > When enabled, the new machinery works as follows: > > 1) when memory region is reserved for allocating executable pages, the > whole region is committed with RWX permissions and then decommitted, > 2) since reconfiguration of RWX page permissions is not allowed on > MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts > to change them, > 3) the request to set RWX permissions in the executable page region > just recommits the pages without changing permissions (see (1), they > were already allocated as RWX and then discarded), > 4) in order to make executable pages inaccessible one must use > OS::DiscardSystemPages() instead of OS::DecommitPages() or > setting permissions to kNoAccess because the latter two are not > allowed by the MacOS (see (2)). > 5) since code space page headers are allocated as RWX pages it's also > necessary to switch between W^X modes when updating the data in the > page headers (i.e. when marking, updating stats, wiring pages in > lists, etc.). The new CodePageHeaderModificationScope class is used > in the respective places. On unrelated configurations it's a no-op. > > The fast permission switching can't be used for V8 configuration with > enabled pointer compression and disabled external code space because > a) the pointer compression cage has to be reserved with MAP_JIT flag > which is too expensive, > b) in case of shared pointer compression cage if the code range will > be deleted while the cage is still alive then attempt to configure > permissions of pages that were previously set to RWX will fail. > > This also CL extends the unmapper unit tests with permissions tracking > for discarded pages. > > Bug: v8:12797 > Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Igor Sheludko <ishell@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80238} Bug: v8:12797 Change-Id: Ic07948e036db36326d464a2a901d052aa060a406 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3611665 Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Adam Klein <adamk@chromium.org> Cr-Commit-Position: refs/heads/main@{#80239}
-
Igor Sheludko authored
... for V8 code space. The feature is currently disabled. In order to use fast W^X permission switching we must allocate executable pages with readable writable executable permissions (RWX). However, MacOS on ARM64 ("Apple M1"/Apple Silicon) prohibits further permission changing of RWX memory pages. This means that the code page headers must be allocated with RWX permissions too because otherwise it wouldn't be possible to allocate a large code page over the freed regular code page and vice versa. When enabled, the new machinery works as follows: 1) when memory region is reserved for allocating executable pages, the whole region is committed with RWX permissions and then decommitted, 2) since reconfiguration of RWX page permissions is not allowed on MacOS on ARM64 ("Apple M1"/Apple Silicon), there must be no attempts to change them, 3) the request to set RWX permissions in the executable page region just recommits the pages without changing permissions (see (1), they were already allocated as RWX and then discarded), 4) in order to make executable pages inaccessible one must use OS::DiscardSystemPages() instead of OS::DecommitPages() or setting permissions to kNoAccess because the latter two are not allowed by the MacOS (see (2)). 5) since code space page headers are allocated as RWX pages it's also necessary to switch between W^X modes when updating the data in the page headers (i.e. when marking, updating stats, wiring pages in lists, etc.). The new CodePageHeaderModificationScope class is used in the respective places. On unrelated configurations it's a no-op. The fast permission switching can't be used for V8 configuration with enabled pointer compression and disabled external code space because a) the pointer compression cage has to be reserved with MAP_JIT flag which is too expensive, b) in case of shared pointer compression cage if the code range will be deleted while the cage is still alive then attempt to configure permissions of pages that were previously set to RWX will fail. This also CL extends the unmapper unit tests with permissions tracking for discarded pages. Bug: v8:12797 Change-Id: Idb28cbc481306477589eee9962d2e75167d87c61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3579303Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80238}
-
- 26 Apr, 2022 1 commit
-
-
Igor Sheludko authored
It's necessary to support fast W^X permission switching on MacOS on ARM64 ("Apple M1"/Apple Silicon) where permission modification of RWX pages to anything else is prohibited. On all the other architectures/platforms RecommitPages() is equivalent to SetPermissions(). The new API will be used in a follow-up CLs. Bug: v8:12797 Change-Id: Id0d8b8c42c81b80cd8fa6b47c227680d7d1f9b10 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606231Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Samuel Groß <saelo@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80190}
-
- 25 Apr, 2022 1 commit
-
-
Igor Sheludko authored
This CL extends BoundedPageAllocator with PageFreeingMode parameter which controls how pages should be freed: by setting permissions to kNoAccess (preferred) or by discarding pages (Apple Silicon specific behavior for RWX pages). The latter mode allows to ensure that once pages are configured with RWX permissions they are never reconfigured to anything else again. The new mode will be used in a follow-up CL. Bug: v8:12797 Change-Id: I3277f56ea6fee9c9b38b1682e68c22e66e9a02a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606228Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#80162}
-
- 24 Feb, 2022 1 commit
-
-
Clemens Backes authored
{FreePages} is never expected to fail, and each caller wraps the call in a CHECK macro. In order to learn more about failures, this CL moves the CHECK inside of {::FreePages}, to fail whenever the {PageAllocator} fails to free pages. As a next step, I'll audit our {PageAllocator} implementations to ensure that none of them return {false} for {FreePages}. Note that this is already the case for the gin platform (chromium). R=mlippautz@chromium.org Bug: v8:12656, chromium:1299735 Change-Id: Ib61be6cc8da0110ead2db1ad005728bd061e0243 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3484321Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79248}
-
- 26 Jan, 2022 1 commit
-
-
Igor Sheludko authored
1) when generating short builtin calls/jumps assemblers should use the offset from the CodeRange base rather than the start of the code range reservation because otherwise it's not guaranteed that the PC-relative offset will fit into architecture's constraints. The code range reservation start could be different from the code range base in the following cases: * when the "base bias size" is non-zero (on Windows 64), * when we ended up over-reserving the address space for the code range, which happens as a last resort to fulfil the CodeRange alignment requirements. See the VirtualMemoryCage description for details. Drive-by fixes: 2) in case of over-reserving address space for external code range, the pre-calculated hint for where the remapped embedded builtins should be copied to was outside of the allocatable CodeRange region and thus useless. The fix is to use the allocatable region instead of the reservation region when calculating the hint. 3) when allocating CodeRange with zero base bias size we can create the VirtualMemory reservation from the first attempt simply by passing the required base alignment to the VirtualMemory constructor. Bug: v8:11880, chromium:1290591 Change-Id: If341418947e2170d967e22b38bcc371594939c1c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3412089Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78772}
-
- 15 Dec, 2021 1 commit
-
-
Samuel Groß authored
This CL renames a number of things related to the V8 sandbox. Mainly, what used to be under V8_HEAP_SANDBOX is now under V8_SANDBOXED_EXTERNAL_POINTERS, while the previous V8 VirtualMemoryCage is now simply the V8 Sandbox: V8_VIRTUAL_MEMORY_CAGE => V8_SANDBOX V8_HEAP_SANDBOX => V8_SANDBOXED_EXTERNAL_POINTERS V8_CAGED_POINTERS => V8_SANDBOXED_POINTERS V8VirtualMemoryCage => Sandbox CagedPointer => SandboxedPointer fake cage => partially reserved sandbox src/security => src/sandbox This naming scheme should simplify things: the sandbox is now the large region of virtual address space inside which V8 mainly operates and which should be considered untrusted. Mechanisms like sandboxed pointers are then used to attempt to prevent escapes from the sandbox (i.e. corruption of memory outside of it). Furthermore, the new naming scheme avoids the confusion with the various other "cages" in V8, in particular, the VirtualMemoryCage class, by dropping that name entirely. Future sandbox features are developed under their own V8_SANDBOX_X flag, and will, once final, be merged into V8_SANDBOX. Current future features are sandboxed external pointers (using the external pointer table), and sandboxed pointers (pointers guaranteed to point into the sandbox, e.g. because they are encoded as offsets). This CL then also introduces a new build flag, v8_enable_sandbox_future, which enables all future features. Bug: v8:10391 Change-Id: I5174ea8f5ab40fb96a04af10853da735ad775c96 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322981Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78384}
-
- 06 Dec, 2021 1 commit
-
-
Samuel Groß authored
When leak sanitizer is active, an LsanVirtualAddressSpace is used and takes care of marking the allocated pages as lsan root regions. Bug: chromium:1276767 Change-Id: I3d8a61f7d3c59e4574e46707d2217031a32e3f0e Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3314828 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78251}
-
- 04 Dec, 2021 1 commit
-
-
Samuel Groß authored
This interface is meant to eventually replace the existing v8::PageAllocator interface. Beyond general refactoring of the PageAllocator APIs, the new interface now supports the concept of (contiguous) address space reservations, which previously had to be implemented through page allocations. These reservations now make better use of provided OS primitives on Fuchsia (VMARs) and Windows (placeholder mappings) and can be used to back many of the cages and virtual memory regions that V8 creates. The new interface is not yet stable and may change at any time without deprecating the old version first. Bug: chromium:1218005 Change-Id: I295253c42e04cf311393c5dab9f8c06bd7451ce3 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301475 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78235}
-
- 11 Nov, 2021 1 commit
-
-
Ng Zhi An authored
Bug: v8:12244,v8:12245 Change-Id: I2d1f9f24b8a78b8025c73e065e79c72c842a939b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3273528Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77854}
-
- 19 Oct, 2021 1 commit
-
-
Samuel Groß authored
Bug: v8:10391 Change-Id: Ia123d8034c4ade76c9843df5d947fdc4ee3d8e35 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226337Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77454}
-
- 14 Oct, 2021 1 commit
-
-
Samuel Groß authored
There is no need to wrap the cage's page allocator into a LsanPageAllocator as that page allocator ultimately relies on the platform page allocator to obtain pages. As the platform page allocator will be a LsanPageAllocator when LSAN is enabled, it will already take care of marking the pages as root regions with LSAN. luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Bug: chromium:1218005 Change-Id: I62b5da9cb320e5012a657951c0d4c85a1bb2b3fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3222761Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77403}
-
- 07 Oct, 2021 1 commit
-
-
Samuel Groß authored
Currently, when compiling with V8_VIRTUAL_MEMORY_CAGE enabled, the behavior of the BoundedPageAllocator changes from simply making freed pages inaccessible to decommitting them, which guarantees that they will be zero-initialized after the next allocation. As this seems to cause some performance regressions on Mac, this CL introduces a new enum that specifies how the allocator should behave: kAllocatedPagesMustBeZeroInitialized causes the pages to be decommitted during FreePages() and ReleasePages() and thus guarantees zero-initialization during AllocPages(). kAllocatedPagesCanBeUninitialized only causes the pages to be made inaccessible, and so does not generally guarantee zero-initialization for AllocPages(). Finally, this CL also removes some dead code in allocation.cc. Bug: chromium:1257089 Change-Id: I53fa52c8913df869bee2b536efe252780d1ad893 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3208812 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77285}
-
- 06 Oct, 2021 1 commit
-
-
Hao Xu authored
Allocate code range close to binary (<2GB) when pointer compression is disabled. And enable short builtin calls if it succeeds. Bug: v8:12045, v8:11527 Change-Id: I1a9d635b243337980fd75883d9802bc0cee75e43 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3069457 Commit-Queue: Hao A Xu <hao.a.xu@intel.com> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77248}
-
- 23 Sep, 2021 1 commit
-
-
Anton Bikineev authored
The CL provides a way for the embedder to hook in a special malloc-like allocator that will be used for zone allocations. An alternative approach would be to use weak functions with branches, checking whether the functions were available at link-time. Those branches could be optimized away with LTOs, so they would essentially be free. However, the weak function approach is not portable (e.g. there is no easy way to emulate it with msvc). The approach can be revisited if indirect call turns out to be expensive (e.g. on hardware with weak branch target predictors). The CL is a prerequisite for running PCScan in the renderer process. Bug: chromium:1249550 Change-Id: I221dcb2486c13e8e6e6761839ba391978319bde4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3172760Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Anton Bikineev <bikineev@chromium.org> Cr-Commit-Position: refs/heads/main@{#77012}
-
- 17 Sep, 2021 1 commit
-
-
Samuel Groß authored
Instead of explicitely splitting the cage into two separate regions, we now just create a single BoundedPageAllocator to manage the entire address range of the cage, then allocate the first 4GB for the pointer compression cage. Bug: chromium:1218005 Change-Id: I02c53ca8b6dda9074ae6caccc74c32bd6271d4d2 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162044Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#76900}
-
- 11 Aug, 2021 1 commit
-
-
Samuel Groß authored
When this is enabled, v8 reserves a large region of virtual address space during initialization, at the start of which it will place its 4GB pointer compression cage. The remainder of the cage is used to store ArrayBuffer backing stores and WASM memory buffers. This will later allow referencing these buffers from inside V8 through offsets from the cage base rather than through raw pointers. Bug: chromium:1218005 Change-Id: I300094b07f64985217104b14c320cc019f8438af Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3010195Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@google.com> Cr-Commit-Position: refs/heads/master@{#76234}
-
- 19 Jul, 2021 1 commit
-
-
Clemens Backes authored
A stray 0xfeff character was accidentally added in https://crrev.com/c/2952864, causing compilation problems on some platforms. This CL removes it. In case your diff looks empty, this is the change: -<feff>// Copyright 2012 the V8 project authors. All rights reserved. +// Copyright 2012 the V8 project authors. All rights reserved. It was generated via > git checkout -p 9c904a8f^ src/utils/alloca*.cc R=leszeks@chromium.org Bug: v8:11968 Change-Id: Ief3eba7875383c4a4c4238a4af47083304fc9782 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038526Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75788}
-
- 01 Jul, 2021 1 commit
-
-
John Xu authored
- Updated implementation of platform-starboard - Introducing stack_trace_starboard.cc - Adding Starboard implementation for sys-info, random and memory - Disabling some code in ostream. Bug: v8:10927 Change-Id: I4548a413449fc8e43c5d4ae485b3644c60c07830 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2952864 Commit-Queue: John Xu <johnx@google.com> Auto-Submit: John Xu <johnx@google.com> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#75495}
-
- 18 Jun, 2021 1 commit
-
-
Dan Elphick authored
The adding of base:: was mostly prepared using git grep and sed: git grep -l <pattern> | grep -v base/vector.h | \ xargs sed -i 's/\b<pattern>\b/base::<pattern>/ with lots of manual clean-ups due to the resulting v8::internal::base::Vectors. #includes were fixed using: git grep -l "src/utils/vector.h" | \ axargs sed -i 's!src/utils/vector.h!src/base/vector.h!' Bug: v8:11879 Change-Id: I3e6d622987fee4478089c40539724c19735bd625 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968412Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75243}
-
- 30 Apr, 2021 1 commit
-
-
Clemens Backes authored
cpplint rules change over time, and we change the exact rules we enable for v8. This CL removes NOLINT annotations which are not needed according to the currently enabled rules. R=mlippautz@chromium.org Bug: v8:11717 Change-Id: I26602ad8aa509646053ec1bdd79470116b89dc3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859853 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#74292}
-
- 26 Apr, 2021 1 commit
-
-
Michael Lippautz authored
- Move LsanPageAllocator to base; - Use LsanPageAllocator in PageBackend that serves managed C++ objects; - Remove spurious TODO for GCInfoTable which should not use the LSAN-aware backend; Bug: chromium:1056170 Change-Id: I2caa11443ab44da5164f1c29339e302bffb49228 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2850157 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#74192}
-
- 19 Apr, 2021 1 commit
-
-
Shu-yu Guo authored
The plan is to use VirtualMemoryCage both for the pointer compression cage as well as the code range in a future CL. The PtrComprCage class is removed in favor of using VirtualMemoryCage directly. Bug: v8:11460 Change-Id: I4e34a3db1359319e3539ede587f6a73e0af03eec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2824098 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Junliang Yan <junyan@redhat.com> Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#74048}
-
- 17 Nov, 2020 1 commit
-
-
John Xu authored
Bug: v8:10927 Change-Id: Icbdc0d7329ddd466e7d67a954246a35795b4dece Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2507310 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#71220}
-
- 07 Oct, 2020 1 commit
-
-
Jakob Kummerow authored
This is a "minimal" change to achieve the required goal: seeing that there is only one place where we need to indicate that memory should be reserved with MAP_JIT, we can add a value to the Permissions enum instead of adding a second, orthogonal parameter. That way we avoid changing public API functions, which makes this CL easier to undo once we have platform-independent w^x in Wasm. Bug: chromium:1117591 Change-Id: I6333d69ab29d5900c689f08dcc892a5f1c1159b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2435365 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#70379}
-
- 31 Jul, 2020 1 commit
-
-
Dan Elphick authored
This allows the configuration v8_enable_shared_ro_heap and v8_enable_pointer_compression on Linux and Android, although it still defaults to off. When pointer compression and read-only heap sharing are enabled, sharing is achieved by allocating ReadOnlyPages in shared memory that are retained in the shared ReadOnlyArtifacts object. These ReadOnlyPages are then remapped into the address space of the Isolate ultimately using mremap. To simplify the creation process the ReadOnlySpace memory for the first Isolate is created as before without any sharing. It is only when the ReadOnlySpace memory has been finalized that the shared memory is allocated and has its contents copied into it. The original memory is then released (with PC this means it's just released back to the BoundedPageAllocator) and immediately re-allocated as a shared mapping. Because we would like to make v8_enable_shared_ro_heap default to true at some point but can't make this conditional on the value returned by a method in the code we are yet to compile, the code required for sharing has been mostly changed to use ifs with ReadOnlyHeap::IsReadOnlySpaceShared() instead of #ifdefs except where a compile error would result due to the absence of a class members without sharing. IsReadOnlySpaceShared() will evaluate CanAllocateSharedPages in the platform PageAllocator (with pointer compression and sharing enabled) once and cache that value so sharing cannot be toggled during the lifetime of the process. Bug: v8:10454 Change-Id: I0236d752047ecce71bd64c159430517a712bc1e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2267300 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#69174}
-
- 16 Jan, 2020 1 commit
-
-
Bill Ticehurst authored
Add the necessary V8_EXPORT_PRIVATE attributes and a few other minor changes to make building DLLs with MSVC happy. (Note: Debug builds still seem to be failing in Torque, but this fixes Release builds). Bug: v8:8791 Change-Id: Ia4d5372fd1cb961e6268a2b5c089bcd17822f1e5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1996157Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65822}
-
- 16 Sep, 2019 1 commit
-
-
Clemens Hammacher authored
This randomizes new memory allocations and reservations. It's currently used to test far jump tables in wasm better, but might be helpful generally for testing arbitrary virtual memory layouts. R=mstarzinger@chromium.org Bug: v8:9477 Change-Id: Ie60b7c6dd3c4cd0f3b9eb8e2172912e0851c357d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1803340 Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/master@{#63802}
-
- 04 Sep, 2019 2 commits
-
-
Clemens Hammacher authored
R=mlippautz@chromium.org Bug: v8:9396 Change-Id: If197687b6208257be18f91b4b172ec41600c21b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784287Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63555}
-
Clemens Hammacher authored
The "address" pointer we pass to {Allocate} and {AllocatePages} functions is actually just a hint. The actual address of the reservation is returned by the function. This CL renames the {address} argument of those functions to {hint} to make this semantic more clear. R=mlippautz@chromium.org Bug: v8:9396 Change-Id: I9ff3785ea4e6f9b7d77f26f224445f3f92e11f22 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1784280Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#63549}
-
- 15 Jul, 2019 1 commit
-
-
Clemens Hammacher authored
According to the specification, class-specific {operator new} and {operator delete} should be static methods. Interestingly, if the {static} keyword is missing, the methods are implicitly static anyway. This is confusing, so this CL adds the {static} keywords explicitly. It also removes the redundant {Malloced::New} and {Malloced::Delete} methods. R=mlippautz@chromium.org Bug: v8:9396 Change-Id: I1db7c87b816567cc1a9153d0b18e3dd4ae81dd6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1700080Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#62703}
-
- 24 May, 2019 1 commit
-
-
Yang Guo authored
TBR=mvstanton@chromium.org,neis@chromium.org,ahaas@chromium.org Bug: v8:9247 Change-Id: I5433c863a54f3412d73df0d38aba3fdbcfac7ebe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627973 Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Yang Guo <yangguo@chromium.org> Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61830}
-
- 23 May, 2019 1 commit
-
-
Yang Guo authored
NOPRESUBMIT=true TBR=mstarzinger@chromium.org Bug: v8:9247 Change-Id: I4cd6b79a1c2cba944f6f23caed59d4f1a4ee358b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624217 Commit-Queue: Yang Guo <yangguo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jaroslav Sevcik <jarin@chromium.org> Cr-Commit-Position: refs/heads/master@{#61790}
-
- 21 May, 2019 1 commit
-
-
Yang Guo authored
TBR=hpayer@chromium.org NOPRESUBMIT=true Bug: v8:9247 Change-Id: I3d49c1c748fe5109523d4cd122ba925f20cfc60b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619755Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#61685}
-
- 06 May, 2019 1 commit
-
-
Clemens Hammacher authored
Use the existing move assignment operator instead. R=ulan@chromium.org Bug: v8:9183 Change-Id: Id7a4427da2bbf92d2954faba06e24afe64cb9818 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1594729Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61236}
-
- 29 Apr, 2019 1 commit
-
-
Clemens Hammacher authored
The {Vector} class does not use it any more. External uses should be converted to {size_t} instead of {int}. This CL removes the function from vector.h and updates all users to either use {size_t}, or cast to {int} explicitly. In tests, no further checks are needed if the string is a constant. R=mstarzinger@chromium.org Bug: v8:9183 Change-Id: I60f99302504c74d8a7c79b147ca01d8ba61b6879 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587393Reviewed-by:
Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Clemens Hammacher <clemensh@chromium.org> Cr-Commit-Position: refs/heads/master@{#61092}
-