- 07 Dec, 2021 2 commits
-
-
Clemens Backes authored
D8 shares counters across isolates, so even if they are only updated from the main thread, they need to be thread-safe. This CL removes the distinction between {StatsCounter} and {StatsCounterThreadSafe}, and just makes all {StatsCounter} use (cheap) atomic operations for counter updates. This will make previously thread-safe counters cheaper, because no Mutex is involved. It might make previously not-thread-safe counters slightly more expensive, but it's not expected to be a significant regression. R=mlippautz@chromium.org Bug: v8:12481, v8:12482 Change-Id: I47b8681c1cf26d142e1ccfafa0c192e3fdcb7d2a Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3320427Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#78278}
-
Shu-yu Guo authored
MSVC disallows inline assembly on x64 and arm64, and instead requires use of compiler intrinsics [0]. This CL checks for MSVC and uses intrinsics for yield/pause, where available. [0] https://docs.microsoft.com/en-us/cpp/intrinsics/compiler-intrinsics?view=msvc-170 Cq-Include-Trybots: luci.v8.try:v8_win64_msvc_rel_ng Change-Id: I3b9cbd998e91b391a21f1443e83758e7242425c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3318721 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78268}
-
- 06 Dec, 2021 3 commits
-
-
Shu-yu Guo authored
For shared strings, String::MakeThin is protected by using the map word of the string being migrated as a spinlock. Note that this CL does not make it safe yet to access character data from multiple threads. The spinlock here only protects write-write races in String::MakeThin. For more information, see the following two design docs: https://docs.google.com/document/d/1c5i8f2EfKIQygGZ23hNiGxouvRISjUMnJjNsOodj6z0/edit https://docs.google.com/document/d/1Drzigf17t4ofy0evDmaIL5p0MDZuAl95c9fSeX-QjVg/edit Bug: v8:12007 Change-Id: I9c47412c6ec7360a672b65a8576b4f6156ee5846 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313429 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#78257}
-
Samuel Groß authored
On Intel chips, MAP_JIT is required when the hardened runtime is enabled, which it is in Chrome. Without MAP_JIT, it is then not possible to allocate executable pages in an address space reservation. Bug: chromium:1276887 Change-Id: I632fdfc9e6cf02bac95e630e6404fea7d8f4c176 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/+/3310913 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#78255}
-
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}
-
- 03 Dec, 2021 1 commit
-
-
Shu-yu Guo authored
This is in preparation for supporting concurrent access in String::SlowEquals, which will need to compare character buffers with relaxed ordering. Bug: v8:12007 Change-Id: Ie8ac62c15df48ebd605985c35b843b510c7ad167 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313467 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78231}
-
- 30 Nov, 2021 2 commits
-
-
Bruce Dawson authored
For years win32-headers.h has "helpfully" set _WIN32_WINNT if it has not already been set. This has caused problems because the value specified in win32-headers.h falls behind that set in the config files. This change removes the fallback and makes it an error to not set this macro in the build config files. This only affects MinGW builds where it has caused confusion. Bug: v8:12099 Change-Id: I013aadc307376fa97afa7b7752910f4fa4a6db82 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3272648Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/main@{#78168}
-
Samuel Groß authored
Instead of potentially mapping a larger region than requested, then unmapping parts of it to obtain a mapping with the desired alignment, we now compute the ZX_VM_ALIGN_X constant corresponding to the specified alignment and use that in the call to zx_vmar_map. Bug: chromium:1218005 Change-Id: Ia36de6a06f3f2d625d177320d7e46fd29331f711 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3307054Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#78164}
-
- 29 Nov, 2021 1 commit
-
-
Samuel Groß authored
This low-level API implements virtual address space reservations on the supported platforms. An AddressSpaceReservation supports similar functionality as the global page management APIs in the OS class but operates inside a continuous region of previously reserved virtual address space. A reservation is backed by regular mmap mappings on Posix, by placeholder mappings on Windows, and by VMARs on Fuchsia. Bug: chromium:1218005 Change-Id: I99bc6bcbc26eb4aa3b54a31c671c9e06e92c471b 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/+/3270540 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78130}
-
- 25 Nov, 2021 1 commit
-
-
Ben Noordhuis authored
PTHREAD_STACK_MIN is an alias for __sysconf(__SC_THREAD_STACK_MIN_VALUE) in glibc 2.34. __sysconf() returns long, causing a -Werror,-Wsign-compare error build error. Change-Id: I15da8e7ee57a6979682ff7166990698965481586 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3301464 Commit-Queue: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#78097}
-
- 19 Nov, 2021 1 commit
-
-
Samuel Groß authored
Previously, an allocation from a separate thread could grab the just-released region and make it accessible before the regions permissions are changed to kNoAccess at the end of ReleasePages. Bug: v8:12414 Change-Id: I98c8f8e3df76d4a44c357ddab107cfeff20049b8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3293083Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77997}
-
- 15 Nov, 2021 1 commit
-
-
Samuel Groß authored
This change allows clients of the RegionAllocator to provide callbacks that are invoked when regions are split or merged. This will later be needed on Windows when a RegionAllocator is used to manage a placeholder mapping as these need to be split and merged (using the VirtualFree API) as well. Bug: chromium:1218005 Change-Id: I228b41bdb43c4a9ef0db04de9b121dea6b5f12f9 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3264287 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@{#77903}
-
- 08 Nov, 2021 1 commit
-
-
Jakob Gruber authored
This CL adds an Allocator to SmallVector to control how dynamic storage is managed. The default value uses the plain old C++ std::allocator<T>, i.e. acts like malloc/free. For use with zone memory, one can pass a ZoneAllocator as follows: // Allocates in zone memory. base::SmallVector<int, kInitialSize, ZoneAllocator<int>> xs(ZoneAllocator<int>(zone)); Note: this is a follow-up to crrev.com/c/3240823. Drive-by: hide the internal `reset` function. It doesn't free the dynamic backing store; that's a surprise and should not be exposed to external use. Change-Id: I1f92f184924541e2269493fb52c30f2fdec032be Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3257711 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77755}
-
- 25 Oct, 2021 1 commit
-
-
Omer Katz authored
Bug: v8:12050 Change-Id: I599338eba458e177327870699b6ea8a423e144c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211577 Commit-Queue: Wez <wez@chromium.org> Auto-Submit: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Wez <wez@chromium.org> Cr-Commit-Position: refs/heads/main@{#77530}
-
- 20 Oct, 2021 1 commit
-
-
Hao Xu authored
Search for free memory ranges within the +/- 2GB boundary to the embedded builtins. So that code range can be allocated close to the binary to enable short builtin calls when pointer compression is disabled. Bug: v8:12045, v8:11527 Change-Id: I4698625882c3c7c39aff73b0bc874ddcfc990881 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3212466 Commit-Queue: Hao A Xu <hao.a.xu@intel.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77465}
-
- 19 Oct, 2021 1 commit
-
-
Peter Kasting authored
Bug: chromium:1203071 Change-Id: I32481d9918aa4a86510570dfb4997f7645f0df23 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226965 Auto-Submit: Peter Kasting <pkasting@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#77451}
-
- 14 Oct, 2021 3 commits
-
-
Samuel Groß authored
The virtual memory cage supports a fallback mode that attempts to obtain memory pages within a specific virtual address range by using PageAllocator hints. However, Prior to this CL, the default PageAllocator on Fuchsia would ignore hints alltogether, preventing these mechanisms from working there. Ultimately, on Fuchsia it would probably be better to manage the virtual memory cage purely through VMARs instead of actually creating pseudo mappings just to reserve virtual address space as is currently done through the PageAllocator. This will require broader changes though, so in the meantime, sticking to the current PageAllocator API is probably the best option. Bug: chromium:1218005 Change-Id: I821cfbb815d81479c3b3310296302addbb9cd8f5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220340Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77398}
-
Samuel Groß authored
Besides the virtual memory cage, the DecommitPages API is also now required for Cppgc with crrev/c/3211583. A working implementation of this API is availabe in src/base/platform for all supported platforms and is used by the DefaultPlatform. Bug: chromium:1218005 Change-Id: I29765993ed54bb52de71998ae8c6295637ee4072 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211584 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77396}
-
Samuel Groß authored
This function tries to determine the number of virtual address bits available on the current CPU and with that the maximum size of the userspace address space. On x64, it can be implemented through CPUID. The result of this function is now used in two ways: first, it limits the maximum size of the virtual memory cage, currently to a quarter of the address space. Second, it influences the placement of fake cages, which are attempted to be placed into the lower half of the address space so that they are followed by large amounts of (hopefully) unused but addressable virtual memory in which pages can be allocated. Bug: chromium:1218005 Change-Id: I0edc5d241d899f16dbc47492fa1534b6aaa4aa13 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220348 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77393}
-
- 13 Oct, 2021 1 commit
-
-
Samuel Groß authored
This is a reland of 1ea76c13 Disabled the failing test on Fuchsia until its PageAllocator respects allocation hints. Original change's description: > Implement a fake virtual memory cage mechanism > > On operating systems where reserving virtual address space is expensive, > notably Windows pre 8.1, it is not possible to create a proper virtual > memory cage. In order to still be able to reference caged objects > through offsets from the cage base on these systems, this CL introduces > a fake cage mechanism. When the fake cage is used, most of the virtual > memory for the cage is not actually reserved. Instead, the cage's page > allocator simply relies on hints to the OS to obtain pages inside the > cage. This does, however, not provide the same security benefits as a > real cage as unrelated allocations might end up inside the cage. > > Bug: chromium:1218005 > Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 > 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/+/3217200 > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77367} Bug: chromium:1218005 Change-Id: I2ed95d121db164679c38085115e8fa92690c057e 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/+/3220151Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77378}
-
- 12 Oct, 2021 2 commits
-
-
Deepti Gandluri authored
This reverts commit 1ea76c13. Reason for revert: The unit test added fails on the Fuchsia bot https://ci.chromium.org/p/v8/builders/ci/V8%20Fuchsia/25976? Original change's description: > Implement a fake virtual memory cage mechanism > > On operating systems where reserving virtual address space is expensive, > notably Windows pre 8.1, it is not possible to create a proper virtual > memory cage. In order to still be able to reference caged objects > through offsets from the cage base on these systems, this CL introduces > a fake cage mechanism. When the fake cage is used, most of the virtual > memory for the cage is not actually reserved. Instead, the cage's page > allocator simply relies on hints to the OS to obtain pages inside the > cage. This does, however, not provide the same security benefits as a > real cage as unrelated allocations might end up inside the cage. > > Bug: chromium:1218005 > Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 > 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/+/3217200 > Commit-Queue: Samuel Groß <saelo@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77367} Bug: chromium:1218005 Change-Id: I541bb9656ab2a6a080c2a30d372226fcc5c95391 Cq-Include-Trybots: luci.v8.try:v8_linux64_heap_sandbox_dbg_ng,v8_linux_arm64_sim_heap_sandbox_dbg_ng No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3219086 Auto-Submit: Deepti Gandluri <gdeepti@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/main@{#77368}
-
Samuel Groß authored
On operating systems where reserving virtual address space is expensive, notably Windows pre 8.1, it is not possible to create a proper virtual memory cage. In order to still be able to reference caged objects through offsets from the cage base on these systems, this CL introduces a fake cage mechanism. When the fake cage is used, most of the virtual memory for the cage is not actually reserved. Instead, the cage's page allocator simply relies on hints to the OS to obtain pages inside the cage. This does, however, not provide the same security benefits as a real cage as unrelated allocations might end up inside the cage. Bug: chromium:1218005 Change-Id: Ie5314be23966ed0042a017917b63595481b5e7e3 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/+/3217200 Commit-Queue: Samuel Groß <saelo@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77367}
-
- 08 Oct, 2021 1 commit
-
-
Samuel Groß authored
This allocator was only required to ensure zero-initialization of pages returned by the BoundedPageAllocator. With crrev/c/3208812, this is now possible in a (hopefully) more efficient way by using the kAllocatedPagesMustBeZeroInitialized PageInitializationMode. Bug: chromium:1218005 Change-Id: I504248107a54c90285aa9a3a616b334aaa3fcb7a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211583Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77298}
-
- 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 2 commits
-
-
Nico Weber authored
_ReadWriteBarrier() is deprecated, and <atomic> has been available for a while now. Ports part of https://chromium-review.googlesource.com/c/chromium/src/+/2365092 to v8. No behavior change. Bug: chromium:1255114 Change-Id: I9954193a69dad9396a5e9e7450066382de2fb172 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3204827 Auto-Submit: Nico Weber <thakis@chromium.org> Commit-Queue: Hannes Payer <hpayer@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/main@{#77258}
-
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}
-
- 05 Oct, 2021 1 commit
-
-
Samuel Groß authored
Bug: chromium:1218005 Change-Id: I00168c25921fd71d925c71c7b7b9ddafd392e95e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3205901Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/main@{#77237}
-
- 27 Sep, 2021 1 commit
-
-
Jakob Kummerow authored
Bug: v8:12244,v8:12245 Change-Id: I718eea6eb065b2775186322b888f805423d6be1e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3183161 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#77085}
-
- 24 Sep, 2021 1 commit
-
-
Michael Lippautz authored
Introduce IDENTIFIER_WITH_LINE() that can be similarly used in other scope-based macros throughout the codebase. Bug: v8:12244,v8:12245 Change-Id: If9d45b7065d7eb3df0297f35eb9be777b497ea95 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3181524 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77038}
-
- 21 Sep, 2021 1 commit
-
-
Michael Lippautz authored
This reverts commit f2e25f8a. Reason for revert: Breaks GCC 8.4.0 compilation, see bug. Original change's description: > [base] Replace base::Optional with Abseil > > Change base::Optional to an alias of absl::optional. Eventually we > should remove it entirely. > > Bug: v8:11006 > Change-Id: I687d44cc7e7cd0a49a84bcc207231eb6808eef2d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476318 > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76913} Bug: v8:11006, v8:12252 Change-Id: I8048dee676a36551d15f25a31d1e171dae00d975 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3173672 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Michael Lippautz <mlippautz@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#76976}
-
- 17 Sep, 2021 1 commit
-
-
Leszek Swirski authored
Change base::Optional to an alias of absl::optional. Eventually we should remove it entirely. Bug: v8:11006 Change-Id: I687d44cc7e7cd0a49a84bcc207231eb6808eef2d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2476318 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#76913}
-
- 15 Sep, 2021 1 commit
-
-
Clemens Backes authored
This is a reland of a55c82d4, now also fixed for UBSan. Original change's description: > Reland "[wasm][test] Fix test expectation" > > This is a reland of 6f9cde1e, with > special handling for MSan as well. > > Original change's description: > > [wasm][test] Fix test expectation > > > > In the mprotect case, there could be one or multiple succeeding writes > > until we finally crash. Thus do not check that we never successfully > > write, but just check that the last printed statement is *before* a > > write. > > > > R=jkummerow@chromium.org > > > > Bug: v8:12226 > > Change-Id: I04209691a9320a9b29dd0ec364539e062ad2dc03 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160343 > > Commit-Queue: Clemens Backes <clemensb@chromium.org> > > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > > Cr-Commit-Position: refs/heads/main@{#76829} > > Bug: v8:12226 > Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng > Change-Id: I85ca98be43fc1d933d39a4602194e1771c33007c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162037 > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76839} Bug: v8:12226 Change-Id: I911295b73a385c899a993a729db3a499e58b7cb6 Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_ubsan_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162041Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#76841}
-
- 01 Sep, 2021 3 commits
-
-
Jakob Gruber authored
Broken by crrev.com/c/3129420 error: ‘CompilationDependency::AsTransition() const’ defined but not used. Bug: v8:7790 Change-Id: I06839c4d33d3a52909e0e5a276c567eca83e910f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3133147 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#76623}
-
Michael Lippautz authored
Other threads may write the stack of a different thread and use a lock to synchronize such an access. An example for this is interrupt handling. Ignore TSAN for the methods performing the stack walk. There's no need to use relaxed atomic reads as same-thread writes are consistent and for other-thread writes there's no guarantee on what values to observe. Bug: chromium:1245409 Change-Id: Ia3d3621590f1f5524d245632a2e8a2db23313f35 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3135573 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Cr-Commit-Position: refs/heads/main@{#76622}
-
Shu-yu Guo authored
This CL does the following for x64: - Add seq cst TSAN helpers. - Refactors codegen's handling of TSAN helpers to also support seq cst accesses. - Perform stores only once instead twice under TSAN, since duplicating stores is unsound. Previously this was "fine" because all duplicated stores were relaxed. SeqCst stores are used for synchronization, however, and duplicating them breaks the synchronization. Bug: v8:7790, v8:11600, v8:11995 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Change-Id: I43071b0ed516cb0917a10f3b2b9861d74edca041 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3103308 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#76612}
-
- 27 Aug, 2021 1 commit
-
-
Bruce Dawson authored
For historical reasons MinGW used to define a higher value for _WIN32_WINNT. Over years of refactoring this turned into a _lower_ value, which has then started breaking compilation on MinGW. This change gets ride of the MinGW specific value. R: mlippautz@chromium.org Bug: V8:12099 Change-Id: Ic24b71c6767cd4d1b53a6cb6487517dec614cd1a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3123639Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Cr-Commit-Position: refs/heads/main@{#76545}
-
- 26 Aug, 2021 1 commit
-
-
Anton Bikineev authored
On 64bit we guarantee that object alignment and sizes are multiple of the default shadow memory granularity (8 bytes). The CL also introduces CHECKs that the assumption holds. Having kObjectAlignment be multiple of this granularity allows us to check poisoness of each byte of an object. On 32bit we can not do that, since the object alignment requirement is 4 bytes. Bug: chromium:1241514 Change-Id: Ib19667724adaa7bc791ffa054eea618c365d65cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118552 Commit-Queue: Anton Bikineev <bikineev@chromium.org> Auto-Submit: Anton Bikineev <bikineev@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#76499}
-
- 19 Aug, 2021 1 commit
-
-
Milad Fa authored
Passing directories to fopen is not a defined behaviour in C/C++. A new test case added by https://crrev.com/c/3098189 is trying to import directories which is expected to fail. Test however is not passing on some platforms including on S390 Linux as `fopen` is successful, size gets set to 0 and a (non-existent) empty file gets returned. This CL uses `stat` to make sure the path is valid and is not a directory. Change-Id: Ibcc762b21145d2198cba07953387a31f39f59300 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3102346Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Milad Fa <mfarazma@redhat.com> Cr-Commit-Position: refs/heads/main@{#76389}
-
- 17 Aug, 2021 1 commit
-
-
Samuel Groß authored
Changing the protections of a kNoAccess region to something different can fail due to OOM. We should handle this properly. Bug: chromium:1240062 Change-Id: I35e8837a57d66930390067eb0d1ab4bc76709948 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3099685Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Samuel Groß <saelo@chromium.org> Cr-Commit-Position: refs/heads/master@{#76342}
-