- 06 Sep, 2021 1 commit
-
-
Leszek Swirski authored
Remove the BaselineData intermediate structure for baseline code, and write the baseline Code object into the SharedFunctionInfo directly. We still need a pointer to the BytecodeArray/InterpreterData, so re-use the Code object's deoptimization data slot for this (baseline code doesn't have deoptimization data). A consequence of this is that the BytecodeArray pointer becomes immutable when there is baseline code. This means that we cannot install a debug BytecodeArray while baseline code is active (we have to flush it first), and we can't tier-up code with debug BytecodeArray to baseline. Change-Id: I53b93ec4d4c64b833603d7992f246982fcd97596 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3118548 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#76675}
-
- 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}
-
- 03 May, 2021 1 commit
-
-
Leszek Swirski authored
In the 'extra' variant, replace turboprop_as_toptier (which is mostly covered by turboprop) with always_sparkplug, to increase Sparkplug's coverage on tests. Bug: v8:11420 Change-Id: I43b7009d184a03cb163d78f1f8bd05233ef7c34e Fixed: v8:11686 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2862769 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#74324}
-
- 28 Apr, 2021 1 commit
-
-
Shu-yu Guo authored
This CL factors out a CodeRange class out of MemoryAllocator. When V8_COMPRESS_POINTERS_IN_SHARED_CAGE is defined, there is a single CodeRange shared by all Isolates in the process. This also turns short builtins back for both configurations of pointer compression. When sharing a cage, there is a single copy of the re-embedded builtins. Since a shared pointer cage is still experimental, to avoid API churn this CodeRange's size is not configurable and is always the maximal size depending on the underlying platform. Change-Id: Ie94f52746f2c5450247a999cc6071e3914d4cf0c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2819206Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#74261}
-
- 24 Mar, 2021 1 commit
-
-
Igor Sheludko authored
... of physical memory, since builtins re-embedding comes with a memory overhead. Bug: v8:11527 Change-Id: I24b77c3ab63e1891bd4c6134c3f3456921cc2a01 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2784564Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#73632}
-
- 17 Mar, 2021 1 commit
-
-
Igor Sheludko authored
This is a speed-for-memory tradeoff, which can be achieved by re-mapping the builtins code blob into existing code range. The feature can be enabled by v8_enable_short_builtin_calls flag and it's off by default. This CL adds GN flag and updates code generator to emit shorter pc-relative calls/jumps to builtins. However, the runtime doesn't support appearance of the off-heap builtins' PCs that point to the embedded code blob on the stack yet. Bug: v8:11527, v8:11421 Change-Id: Iaba384c549675852beae70739175976ee193ffef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727502Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#73458}
-
- 17 Dec, 2020 1 commit
-
-
Nico Hartmann authored
This CL changes SharedFunctionInfo::GetBytecodeArray to a function template, which is specialized for Isolate and LocalIsolate arguments. This allows main thread only uses to avoid taking a lock. Bug: v8:7790, chromium:1154603 Change-Id: I3462c4e36b66073e09393c01c765dd8a018a98f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595307 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#71833}
-
- 16 Oct, 2020 1 commit
-
-
Pierre Langlois authored
Executable V8 pages include 3 reserved OS pages: one for the writable header and two as guards. On systems with 64k OS pages, the amount of allocatable space left for objects can then be quite smaller than the page size, only 64k for each 256k page. This means regular code objects cannot be larger than 64k, while the maximum regular object size is fixed to 128k, half of the page size. As a result code object never reach this limit and we can end up filling regular pages with few large code objects. To fix this, we change the maximum code object size to be runtime value, set to half of the allocatable space per page. On systems with 64k OS pages, the limit will be 32k. Alternatively, we could increase the V8 page size to 512k on Arm64 linux so we wouldn't waste code space. However, systems with 4k OS pages are more common, and those with 64k pages tend to have more memory available so we should be able to live with it. Bug: v8:10808 Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#70569}
-
- 05 Aug, 2020 1 commit
-
-
Jakob Gruber authored
With the new Turbofan variants (NCI and Turboprop), we need a way to distinguish between them both during and after compilation. We initially introduced CompilationTarget to track the variant during compilation, but decided to reuse the code kind as the canonical spot to store this information instead. Why? Because it is an established mechanism, already available in most of the necessary spots (inside the pipeline, on Code objects, in profiling traces). This CL removes CompilationTarget and adds a new NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine various things about a given code kind (e.g.: does this code kind deopt?). As a (very large) drive-by, refactor both Code::Kind and AbstractCode::Kind into a new CodeKind enum class. Bug: v8:8888 Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#69244}
-
- 22 Jul, 2020 1 commit
-
-
Toan Pham authored
Some platforms disable reading of bytes in the .text section, so move the metadata into a separate .rodata section. Bug: v8:10707 Change-Id: I30ef7a180f489f175c31f9d4dcd02115c9f516c2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2301113 Commit-Queue: Toan Pham <toanpham@google.com> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#68984}
-
- 18 May, 2020 1 commit
-
-
Dan Elphick authored
Splits out MemoryAllocator and CodeRangeAddressHint into memory-allocator.h Bug: v8:10473, v8:10506 Change-Id: I0855f23dd0374ddd68493ee05af7a3a00c84660d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2203206 Auto-Submit: Dan Elphick <delphick@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#67857}
-
- 21 Feb, 2020 1 commit
-
-
Michael Lippautz authored
Jitless mode does not allocate executable memory, so we can avoid reserving memory in such configurations. Bug: v8:10033 Change-Id: Ie6a943084e3bade85848e3219cb4d8779ed34830 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981505 Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#66388}
-
- 17 Dec, 2019 1 commit
-
-
Peter Marshall authored
Add an API on Isolate that returns a sorted vector of code pages allocated within V8. The implementation is designed to be signal-safe, so that the user (the UMA sampling profiler) can access this information from a signal handler, where allocation and taking locks is prohibited. This CL adds the machinery for maintaining the list of allocated code pages. Further CLs will modify the Unwinder API itself to accept the code pages provided by this API. The unwinder API currently uses the reserved virtual-memory range called the CodeRange to identify where all V8 code objects live, but this doesn't exist on arm32 or any 32-bit platform, so this approach adds a way to expose the location of all valid V8 code objects in a signal-safe way for use by the UMA sampling profiler. On 64-bit, this API always gives the code_range and embedded_code_range, and does not maintain a vector of code pages. This is so that we have a unified API on 32 and 64-bit that can be used in exactly the same way by embedders. Design doc: https://docs.google.com/document/d/1VGwUult5AHLRk658VetwEHMOmDDxA2eDQs9lDFMZTE0 Bug: v8:8116 Change-Id: I732509a45121fc54853182481c24d1083275afce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1564068 Commit-Queue: Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#65469}
-