- 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}
-
- 23 Feb, 2022 1 commit
-
-
Jakob Gruber authored
A collection of smallish cleanups and improvements for safepoints. Maintainability: - The class names were not very clear; move Safepoint inside SafepointTableBuilder to clarify that this wrapper class is used during codegen. - Rename DefinePointerSlot/DefineRegister to DefineTaggedStackSlot/DefineTaggedRegister for clarity. - Use named constants instead of -1. - DefineTaggedRegister has no connection to kNoDeoptIndex, remove the DCHECK and comment. - Remove the unused kNumSafepointRegisters constant + other dead code. - Small clarifications in CommonFrame::IterateCompiledFrame. - Rename has_safepoint_info to uses_safepoint_table and refactor s.t. `stack_slots` can be used when `uses_safepoint_table == false`. In this case it just returns 0. Perf: - During codegen, represent stack slots as a growable bit vector instead of a list of int indices. Extend GrowableBitVector functionality to support the above. - Track the minimum index instead of iterating all stack slots in all safepoints before encoding. Bug: v8:7700 Change-Id: If409bc42c825d47fc0074fce51e3b963fd080806 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3483659Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79233}
-
- 14 Feb, 2022 1 commit
-
-
Leszek Swirski authored
Replace the Advance/Done methods on BitVector::Iterator with STL-compatible operator overloads, and add begin/end methods to BitVector itself, so that BitVectors can be iterated with ranged for loops. As a drive-by cleanup, make GrowableBitVector hold the BitVector by value (to avoid needing to allocate one for empty iteration), and remove its unused (and inefficient) Union method. Change-Id: Idcd34e26bfb087e3ec8297b4a769a51bfab4b6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3455803Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79071}
-
- 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}
-
- 21 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Straight-line bytecode with exactly one "next" bytecode (i.e. everything that can't affect control flow) will always have the same "out" liveness as the next bytecode's "in" liveness. For those cases, we can save a bit of time and memory by aliasing the pointers between the bytecode's out liveness and the next bytecode's in liveness, and skipping copying between them. This is done by specializing the current liveness update on whether this is the first pass (which will allocate and initialize the liveness bitvectors) or an update pass (which will revisit loops to collect liveness crossing over the back-edge, and propagate this liveness through the loop bodies). On the first pass, we can delay allocation of the out liveness until we know it needs to be union of multiple in livenesses, and on the update pass we can skip it if it is an alias. As a drive-by, tweak BitVector::CopyFrom to require copying from a vector with the same size (same as Union or Intersect), and move the only different sized vector use (in Resize) to be inline. Change-Id: Iad1b2e1b927a37ad925ef68e2a224152aaa2ba18 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3350452 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/main@{#78425}
-
- 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}
-
- 04 Nov, 2021 1 commit
-
-
Leszek Swirski authored
Remove the concept of JobId from LazyCompileDispatcher, and make SFIs the canonical id for these jobs. This has several consequences: * We no longer split enqueing a job and registering a SFI with that job. We did this previously because we could not allocate SFIs in the Parser -- now with LocalHeap we can, so we do. * We remove the separate Job vector, and make the SFI IdentityMap hold pointers to Jobs directly. This requires a small amount of extra care to deallocate Jobs when removing them from the map, but it means not having to allocate new global handles for jobs. * The SFI is passed into the BackgroundCompileTask instead of the script, so our task finalization doesn't need the SFI anymore. * We no longer need to iterate ParallelTasks after compiling (to register SFIs), so we can get rid of ParallelTasks entirely and access the dispatcher directly from the parser. There are a few drive-bys since we're touching this code: * Jobs are move to have a "state" variable rather than a collection of bools, for stricter DCHECKing. * There's no longer a set of "currently running" jobs, since this was only used to check if a job is running, we can instead inspect the job's state directly. * s/LazyCompilerDispatcher/LazyCompileDispatcher/g Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#77712}
-
- 19 Oct, 2021 2 commits
-
-
Victor Gomes authored
We increment the size before enqueueing the next element. This guarantees that size > 0 when decrementing. Bug: v8:12325 Change-Id: Ida256d9b22a9dd5cacb21312f099ee7186e2ca53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3231335 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77457}
-
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}
-
- 18 Oct, 2021 3 commits
-
-
Victor Gomes authored
This is a reland of 0c459ff5 Original change's description: > [baseline] Concurrent Sparkplug n-thread with synchronised queue > > Installation in the main thread. > Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ > > Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77431} Change-Id: I4ea8f3c026a0a448afcb16f57517ee75cedaf83f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229379 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77437}
-
Leszek Swirski authored
This reverts commit 0c459ff5. Reason for revert: breaks build on M1 (where W^X flag is RO) https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20release%20builder/6999/overview Original change's description: > [baseline] Concurrent Sparkplug n-thread with synchronised queue > > Installation in the main thread. > Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ > > Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77431} Change-Id: I45a952aacf0ad29ebb703a742fdc6da7b0b7c826 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229378 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77433}
-
Victor Gomes authored
Installation in the main thread. Design doc: https://docs.google.com/document/d/1GmEiEt2VDmhY_Ag0PiIcGWKtvQupKgNcMZUvgpfQksk/edit?resourcekey=0-seYa-QJsx1ZbjelluPG1iQ Change-Id: Ifc6eccd44efdf377320c64cf9957c6060334e543 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186831 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77431}
-
- 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}
-
- 16 Sep, 2021 1 commit
-
-
Jakob Gruber authored
This is a refactor-only change in preparation for the upcoming builtins table split. - Define fields through a macro list to avoid some manual boilerplate code. - Consistent names for builtin_entry_table_ and builtin_table_, and update names of related methods as well. - Add Builtins::ToInt to replace manual static_casts. - Move around IsolateData methods s.t. they're in the same order as the underlying fields. Bug: v8:12203 Change-Id: I68cd036b8de1dd2708e2d4579d76bb3baaea5e1c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3162128Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#76874}
-
- 24 Aug, 2021 1 commit
-
-
Dan Elphick authored
This is a reland of d1b27019 Fixes include: Adding missing file to bazel build Forward-declaring classing before friend-classing them to fix win/gcc Add missing v8-isolate.h include for vtune builds Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit Bug: v8:11965 Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76460}
-
- 23 Aug, 2021 2 commits
-
-
Dan Elphick authored
This reverts commit d1b27019. Reason for revert: Broke vtune build, tsan build and possibly others Original change's description: > [include] Split out v8.h > > This moves every single class/function out of include/v8.h into a > separate header in include/, which v8.h then includes so that > externally nothing appears to have changed. > > Every include of v8.h from inside v8 has been changed to a more > fine-grained include. > > Previously inline functions defined at the bottom of v8.h would call > private non-inline functions in the V8 class. Since that class is now > in v8-initialization.h and is rarely included (as that would create > dependency cycles), this is not possible and so those methods have been > moved out of the V8 class into the namespace v8::api_internal. > > None of the previous files in include/ now #include v8.h, which means > if embedders were relying on this transitive dependency then it will > give compile failures. > > v8-inspector.h does depend on v8-scripts.h for the time being to ensure > that Chrome continue to compile but that change will be reverted once > those transitive #includes in chrome are changed to include it directly. > > Full design: > https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing > > Bug: v8:11965 > Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Reviewed-by: Camillo Bruni <cbruni@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76424} Bug: v8:11965 Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#76428}
-
Dan Elphick authored
This moves every single class/function out of include/v8.h into a separate header in include/, which v8.h then includes so that externally nothing appears to have changed. Every include of v8.h from inside v8 has been changed to a more fine-grained include. Previously inline functions defined at the bottom of v8.h would call private non-inline functions in the V8 class. Since that class is now in v8-initialization.h and is rarely included (as that would create dependency cycles), this is not possible and so those methods have been moved out of the V8 class into the namespace v8::api_internal. None of the previous files in include/ now #include v8.h, which means if embedders were relying on this transitive dependency then it will give compile failures. v8-inspector.h does depend on v8-scripts.h for the time being to ensure that Chrome continue to compile but that change will be reverted once those transitive #includes in chrome are changed to include it directly. Full design: https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing Bug: v8:11965 Change-Id: I53b84b29581632710edc80eb11f819c2097a2877 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/main@{#76424}
-
- 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}
-
- 03 Aug, 2021 1 commit
-
-
Bruce Dawson authored
Windows.h causes massive namespace pollution with its defining of many macros, it adds to build times, it disables warnings, and it makes it easier to write non-portable code. This change removes windows.h from V8's win32-headers.h. It does this by replicating the small number of typedefs that are needed and by defining three "proxy" types that are the same size and layout. The V8ToWindowsType functions are used to reinterpret_cast between the types. Prior to this change there were over 760 v8-related source files that include windows.h. After this change there are 16. Bug: chromium:796644 Change-Id: I89efeed47028faae72de2da4f1dae345d8d7746c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042215 Commit-Queue: Bruce Dawson <brucedawson@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#76064}
-
- 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}
-
- 08 Jul, 2021 2 commits
-
-
Clemens Backes authored
This reverts commit 8d3c8093. Reason for revert: Fails on UBSan (nullptr on memcpy): https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20UBSan/17246/overview Original change's description: > [factory] Make NewByteArray return canonical empty byte array > > ... for length = 0, analogously to what e.g. NewFixedArray does. > > Simplify some call sites that had special handling for this case > (there are others that didn't). > > Change-Id: Ib3de5506300e967aca072fad53df7ab04ef68839 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009225 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75629} Change-Id: I0cb1667b98a2f9285706c2623671d532419d1395 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3013358 Auto-Submit: Clemens Backes <clemensb@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#75631}
-
Georg Neis authored
... for length = 0, analogously to what e.g. NewFixedArray does. Simplify some call sites that had special handling for this case (there are others that didn't). Change-Id: Ib3de5506300e967aca072fad53df7ab04ef68839 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3009225Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#75629}
-
- 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}
-
- 24 Jun, 2021 3 commits
-
-
Dan Elphick authored
This is a reland of 9701d4a4 with a small fix for some code landed in between the dry-run and submission. Original change's description: > [base] Move most of src/numbers into base > > Moves all but conversions.*, hash-seed-inl.h and math-random.* into > base, in preparation for moving the parts of conversions that don't > access HeapObjects. > > Also moves uc16 and uc32 out of commons/globals.h into base/strings.h. > > Bug: v8:11917 > Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Auto-Submit: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75354} Bug: v8:11917 Change-Id: Ie1ec9032fe56646a7c7303185cecc70fce5694ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982607Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75368}
-
Nico Hartmann authored
This reverts commit 9701d4a4. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64/40802/overview Original change's description: > [base] Move most of src/numbers into base > > Moves all but conversions.*, hash-seed-inl.h and math-random.* into > base, in preparation for moving the parts of conversions that don't > access HeapObjects. > > Also moves uc16 and uc32 out of commons/globals.h into base/strings.h. > > Bug: v8:11917 > Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Reviewed-by: Clemens Backes <clemensb@chromium.org> > Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> > Auto-Submit: Dan Elphick <delphick@chromium.org> > Cr-Commit-Position: refs/heads/master@{#75354} Bug: v8:11917 Change-Id: Iacf796c95256016fa74f0a910c5bb1a86baa425a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2982605 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#75356}
-
Dan Elphick authored
Moves all but conversions.*, hash-seed-inl.h and math-random.* into base, in preparation for moving the parts of conversions that don't access HeapObjects. Also moves uc16 and uc32 out of commons/globals.h into base/strings.h. Bug: v8:11917 Change-Id: Ife359148bb0961a63833aff40d26331454b6afb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2979595Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75354}
-
- 22 Jun, 2021 3 commits
-
-
Dan Elphick authored
Moves VSNPrintf, SNPrintf and StrNCpy out of utils/utils.h into base/strings.h. Bug: v8:11879 Change-Id: I0e165cb27c42f89c9acd1c6378514b40a90cd18d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972732 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75308}
-
Dan Elphick authored
Now that SimpleStringBuilder is only used in conversions.cc, it can be moved there making it easier to assess its safety and limit further use of this potentially unsafe API. (Additionally unused methods Reset and size are removed). Bug: v8:11917 Change-Id: I0515fe4f34bb8f7e7ea464b75394fa3d03939af1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2978253 Commit-Queue: Dan Elphick <delphick@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75300}
-
Dan Elphick authored
StringBuilder and its base class SimpleStringBuilder aren't very safe and are a potential source of memory leaks or double-frees. This removes the StringBuilder class and converts all of its usages to use the standard library. (As a drive-by, this converts std::ostream* to std::ostream& which is more idiomatic C++). Bug: v8:11917 Change-Id: I0eaf9d60cf49836e65bb28f0e114b33ef8103a61 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2978252 Auto-Submit: Dan Elphick <delphick@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75298}
-
- 18 Jun, 2021 2 commits
-
-
Dan Elphick authored
To try and reduce StringBuilder's dependencies, use std::memcpy instead of the V8-only MemCopy. Change-Id: I576dccd4a2ff1b796314f8e806cbb0c70f6c07f2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2972730 Commit-Queue: Dan Elphick <delphick@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#75244}
-
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}
-
- 17 Jun, 2021 1 commit
-
-
Dan Elphick authored
Replace all uses of NewArray/DeleteArray with new[]/delete[] in utils/vector.h which allows removing the dependency on utils/allocation.h. As a result allocation failures here will not call FatalProcessOutOfMemory any more, but it's likely it wouldn't have been called anyway. Also adds some missing includes that were being previously being brought in via vector.h depending on allocation.h. Bug: v8:11879 Change-Id: I5055b49fad0d06642a9bd3eebb93a6a0e4acca60 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968405Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Simon Zünd <szuend@chromium.org> Auto-Submit: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#75216}
-
- 10 Jun, 2021 1 commit
-
-
John Xu authored
For Cobalt's purpose in the past, we introduced base::Memcpy to intercept memcpy calls and replace it with SbMemoryCopy on Starboard/Cobalt. Recently Cobalt removed SbMemoryCopy because we found out that memcpy implementation is universal. To reduce the cost to maintain base::Memcpy, let us remove it and revert back to raw memcpy. Bug: v8:10927 Change-Id: I060f191f8f1aed8b78ffe4558a3743f3a2da008b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2951462Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: John Xu <johnx@google.com> Cr-Commit-Position: refs/heads/master@{#75070}
-