- 12 Mar, 2021 2 commits
-
-
Milad Fa authored
Also fixed the disassembler to include 10th bit of instruction. Change-Id: Idc6659a8a9d6a291b68537bae533a32970a4441d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2757567 Commit-Queue: Milad Fa <mfarazma@redhat.com> Reviewed-by:
Junliang Yan <junyan@redhat.com> Cr-Commit-Position: refs/heads/master@{#73382}
-
Nico Hartmann authored
This CL moves FunctionTemplateInfo to the list of never serialized objects, allowing direct heap reads. To make this threadsafe, the CL: - adds necessary atomic (relaxed/acquire-release) operations to the accessors of FunctionTemplateInfo. - changes FunctionTemplateInfoRef::LookupHolderOfExpectedType to be usable from the background thread (e.g. no handle construction) with the caveat of skipping optimization in some cases where necessary JSObjects are not serialized. Drive-by: Add missing serialization of objects possibly reachable through CallHandlerInfo::data. Bug: v8:7790 Change-Id: I49cf4f328ecfab368dff9076fde8f5783ead3246 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2679687Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#73364}
-
- 11 Mar, 2021 4 commits
-
-
Clemens Backes authored
This is a reland of 80f5dfda. A condition in pipeline.cc was inverted, which lead to a CSA verifier error. Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} TBR=jgruber@chromium.org Bug: v8:11238 Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73348}
-
Clemens Backes authored
This reverts commit 80f5dfda. Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview Original change's description: > [no-wasm] Exclude src/wasm from compilation > > This is the biggest chunk, including > - all of src/wasm, > - torque file for wasm objects, > - torque file for wasm builtins, > - wasm builtins, > - wasm runtime functions, > - int64 lowering, > - simd scala lowering, > - WasmGraphBuilder (TF graph construction for wasm), > - wasm frame types, > - wasm interrupts, > - the JSWasmCall opcode, > - wasm backing store allocation. > > Those components are all recursively entangled, so I found no way to > split this change up further. > > Some includes that were recursively included by wasm headers needed to > be added explicitly now. > > backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc > because it only tests wasm backing stores. This file is excluded from > no-wasm builds then. > > R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org > > Bug: v8:11238 > Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b > Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 > Commit-Queue: Clemens Backes <clemensb@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/master@{#73344} Bug: v8:11238 Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866 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@{#73346}
-
Clemens Backes authored
This is the biggest chunk, including - all of src/wasm, - torque file for wasm objects, - torque file for wasm builtins, - wasm builtins, - wasm runtime functions, - int64 lowering, - simd scala lowering, - WasmGraphBuilder (TF graph construction for wasm), - wasm frame types, - wasm interrupts, - the JSWasmCall opcode, - wasm backing store allocation. Those components are all recursively entangled, so I found no way to split this change up further. Some includes that were recursively included by wasm headers needed to be added explicitly now. backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc because it only tests wasm backing stores. This file is excluded from no-wasm builds then. R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org Bug: v8:11238 Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73344}
-
Clemens Backes authored
The definition of {wasm::WasmCode} will not be available in no-wasm builds, hence avoid any accesses to WasmCode for logging. Drive-by: Inline enumeration of wasm modules for logging of existing code, to avoid another #if. R=petermarshall@chromium.org, jgruber@chromium.org Bug: v8:11238 Change-Id: I3b78cf90f9ad155b5bea64e0941531aed2d4291a Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2739978Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73338}
-
- 08 Mar, 2021 2 commits
-
-
Seth Brenith authored
This change relands the last part of https://crrev.com/c/2601880 . ScopeInfo has a vestigial 'length' field from when it used to be a FixedArray. This change removes that field, which saves some memory. More specifically: - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which supplied the 'length' field. - Change FactoryBase::NewScopeInfo to allocate the updated object shape. It maintains the existing behavior of filling the newly-allocated object with undefined, even though that's not a valid ScopeInfo and further initialization is required. - Change a few length computations to use HeapObject::kHeaderSize rather than FixedArray::kHeaderSize. - Remove an unnecessary heap verifier function. Change-Id: I9b3980157568fdb0402fa31660949966b401fd31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2733037Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73278}
-
Santiago Aboy Solanes authored
If a method happens on the main thread and only on the main thread (i.e. it will never be run on the background), it is safer to use non-atomic accessors as TSAN will give warnings if we use them improperly. As a drive-by, pass the isolate as a parameter where it was readily available as it saves us from getting the isolate from the object later on. Bug: v8:7790 Change-Id: Id9bdd69254edc60b0331a32fccf1479a95b7d286 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2732669Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#73251}
-
- 05 Mar, 2021 3 commits
-
-
Clemens Backes authored
This removes the {wasm_engine_} field from the isolate if v8_enable_webassembly=false. This avoids any includes from src/wasm in isolate.{h,cc}. Unconditional access to the wasm engine in other parts are also #if'ed out to avoid nullptr accesses. Long-term, the {Isolate::wasm_engine()} method will be fully removed, but this can only be done once src/wasm is excluded from compilation. R=jkummerow@chromium.org, petermarshall@chromium.org Bug: v8:11238 Change-Id: Ie3738884ec17ccc0a3027b91a2415c2c633ca774 Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2737298Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73230}
-
Frank Emrich authored
This CL is part of a series that makes SwissNameDictionary available as a new property backing store. Currently, the flag v8_dict_mode_prototypes allows selecting between NameDictionary and OrderedNameDictionary as the backing store used for all dictionary mode objects. This series of CLs changes this such that enabling the flag causes SwissNameDictionary being used instead of OrderedNameDictionary. The behavior for when the flag is not set remains unchanged (= use NameDictionary). This particular CL just collects many small changes. Note that the changes this CL makes to literal-objects.cc do not fix the problems with the enumeration order of computed property names in classes that currently exist when using OrderedNameDictionary. This will be fixed separately. Bug: v8:11388 Change-Id: I6b98f61c395b4f2788407d6a34363ef8863cce9a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2735834 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#73224}
-
Camillo Bruni authored
- Make explicit that Code::bytecode_offset_table is only used with sparkplug code. - Add more DCHECKs on CodeBuilder setter - Code::source_position_table is always a ByteArray Bug: v8:11429 Change-Id: I27f84f0d6e325ca5b616412084227b9a7198d367 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2721769Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#73217}
-
- 03 Mar, 2021 1 commit
-
-
Seth Brenith authored
This is a partial reland of https://crrev.com/c/2601880 . In preparation for ScopeInfo not being a FixedArrayBase, this change privatizes the FixedArray-style functions that provide access to ScopeInfo fields by index, and moves them from scope-info-inl.h to scope-info.cc. Those functions are still used pretty heavily during initialization (ScopeInfo::Create, etc.), but at least we can avoid presenting them to the rest of the world. This change also introduces a new length() function in ScopeInfo which hides the one inherited from FixedArrayBase and computes the ScopeInfo's length based on its flags, so that there are no remaining readers of the 'length' field. Change-Id: I609754010723b679e5cf00f386020faaab84c17a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718275 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#73151}
-
- 02 Mar, 2021 2 commits
-
-
Sara Tang authored
Design doc: https://docs.google.com/document/d/1xkXj94iExFgLWc_OszTNyNGi523ARaKMWPZTeomhI4U This is the second (and hopefully final!) change list needed to integrate ETW into V8. In particular, we added stack-walking functionality for JIT-ted functions! Some notes on instrumentation: - The gist of getting stack-walking in ETW is we need to emit events with specific event IDs. These events get stitched into a pseudo-PDB that is recognizable by ETW. - Unfortunately, we cannot rely on the TraceLogging API from the first CL, as it does not support specifying event IDs. Instead, Bill Ticehurst wrote an API that peels back the TraceLogging API just enough so that we can specify event IDs. This API is the entirety of etw-metdata.h - We attach a CodeEventHandler that logs a stack-walking event whenever code movement is triggered. Bug: v8:11043 Change-Id: I1bf57c985b7375f045089027855b1c03878abb78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2616221Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sara Tang <sartang@microsoft.com> Cr-Commit-Position: refs/heads/master@{#73145}
-
Clemens Backes authored
This removes all wasm includes from src/debug and src/inspector if webassembly is disabled (v8_enable_webassembly=false). It also removes the definition of {WasmValueObject} and {v8::debug::WasmScript}. This will allow to later fully exclude the src/wasm directory from compilation (once other components are fixed). R=bmeurer@chromium.org, machenbach@chromium.org Bug: v8:11238 Change-Id: I41a1d83d01fbb6c015cdfd6cc063bad90052505d Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726506Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#73138}
-
- 26 Feb, 2021 1 commit
-
-
Clemens Backes authored
This renames more fields holding "ValueKind" or methods operating on "ValueKind" to contain "kind" instead of "type". It also renames "is_reference_type" to "is_reference" on both ValueType and ValueKind, as the "_type" prefix is kind of implicit from the argument. R=manoskouk@chromium.org, jgruber@chromium.org Bug: v8:11477 Change-Id: I7809f1af6e983aebca96e03fe1fbc6ccaa22db72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718063 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#73070}
-
- 23 Feb, 2021 1 commit
-
-
Frank Emrich authored
This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL adds printing and verification functions. Bug: v8:11388 Change-Id: I6af8672f19589f5693ebafbcafb8d59b26749eef Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2704669 Commit-Queue: Frank Emrich <emrich@google.com> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72954}
-
- 22 Feb, 2021 2 commits
-
-
Dan Elphick authored
Currently if gn check is enabled (with v8/third_party ignored), there are many errors due to headers being used without adding the proper dependency in BUILD.gn (or because it's being used transitively without a public_deps chain). This makes the number of errors go from 2114 to 195. Apart from adding dependencies, it also moves _v8_internal_Node_Print from objects-printer.cc to node.cc so it can see the Node::Print method which wouldn't otherwise be possible without a circular dependency. Also removes the previously deleted compiler/graph-builder-tester.h file. Bug: v8:7330 Change-Id: Icb34585fbef621588265cf4267cfc88ecbcf0a72 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2702331Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#72908}
-
Clemens Backes authored
Backends do not care about the concrete type, they only need to know the "kind" (e.g. "ref" or "i32"). In order to prepare Liftoff to use the value kind instead of the value type for all stored data, this CL moves the kind out of the ValueType and makes it a top-level enum. R=manoskouk@chromium.org Bug: v8:11477 Change-Id: I489d6c5207e6ff1b66e2afbe78a156d66df27eb3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2707169 Commit-Queue: Clemens Backes <clemensb@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72896}
-
- 19 Feb, 2021 1 commit
-
-
Seth Brenith authored
This reverts commit f731e13f. Reason for revert: perf regressions, chromium:1179757 Original change's description: > Remove 'length' field from ScopeInfo > > ScopeInfo has a vestigial 'length' field from when it used to be a > FixedArray. This change removes that field, which saves some memory. > > More specifically: > > - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which > supplied the 'length' field. > - Privatize the FixedArray-style functions that provide access to > ScopeInfo fields by index, and move them from scope-info-inl.h to > scope-info.cc. Those functions are still used pretty heavily during > initialization (ScopeInfo::Create, etc.), but at least we can avoid > presenting them to the rest of the world. > - Change FactoryBase::NewScopeInfo to allocate the updated object shape. > It maintains the existing behavior of filling the newly-allocated > object with undefined, even though that's not a valid ScopeInfo and > further initialization is required. > - Move part of AccessorAssembler::ScriptContextTableLookup into a new > Torque macro, because it used to rely on casting ScopeInfo to > FixedArrayBase. > - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are > arrays. I think it makes more sense to list them under "(system)" in > the dev tools, like most other V8 internal types. > > Bug: v8:8952 > Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Mythri Alle <mythria@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72830} Bug: v8:8952 Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Auto-Submit: Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72855}
-
- 17 Feb, 2021 1 commit
-
-
Seth Brenith authored
ScopeInfo has a vestigial 'length' field from when it used to be a FixedArray. This change removes that field, which saves some memory. More specifically: - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which supplied the 'length' field. - Privatize the FixedArray-style functions that provide access to ScopeInfo fields by index, and move them from scope-info-inl.h to scope-info.cc. Those functions are still used pretty heavily during initialization (ScopeInfo::Create, etc.), but at least we can avoid presenting them to the rest of the world. - Change FactoryBase::NewScopeInfo to allocate the updated object shape. It maintains the existing behavior of filling the newly-allocated object with undefined, even though that's not a valid ScopeInfo and further initialization is required. - Move part of AccessorAssembler::ScriptContextTableLookup into a new Torque macro, because it used to rely on casting ScopeInfo to FixedArrayBase. - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are arrays. I think it makes more sense to list them under "(system)" in the dev tools, like most other V8 internal types. Bug: v8:8952 Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72830}
-
- 15 Feb, 2021 3 commits
-
-
Benedikt Meurer authored
Previously we had cached the source position information on JSStackFrame (C++) objects and reused that between calls to GetLineNumber() and GetColumnNumber(). The refactoring in https://crrev.com/eed0d27c2f774b3adbc85d0a5fb30a8cf0f018a8 effectively removed that cache, while still making things faster though. This CL puts back the caching on the StackFrameInfo objects by reusing the `offset` slot to store the computed source position (as indicated by a bit in the `flags`). For promise combinator async frames, the bit is always set and the `offset_or_source_position` slot thus always contains the source position (aka the `promise index` in this case). We also added a `StackFrameInfo::ComputeLocation()` method to remove the last remaining place where we'd peek into the StackFrameInfo from outside stack-frame-info.{cc,h}. Also-By: kimanh@chromium.org Bug: chromium:1077657, v8:8742, chromium:1069425 Change-Id: I59e26a91965617163776e6cc2610b88e6925452c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695386 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72752}
-
pthier authored
The check was a leftover from a debugging session. We don't have a feedback vector even though we have baseline code, e.g. when we share baseline code across realms. In this case the feedback vector will be allocated upon the first invocation of the function. Bug: chromium:1177217 Change-Id: Ia5cde35b0f5d746c2ba64d3ca2083acdfaf286bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2695396 Auto-Submit: Patrick Thier <pthier@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72745}
-
Benedikt Meurer authored
Also block sending "type" as part of the ObjectPreview, but only send the "value" property. The front-end will be updated to display WasmValueObject's similar to what we do for wrapper objects (i.e. StringWrapper and the like). The matching front-end change is still pending. Also refactor the WasmValueObject to have dedicated constructors for the individual types (i32, i64, f32, f64, externref and v128). This way we can just reuse the existing logic in descriptionForObject() and we also don't need to store the "type" on the object itself (not really performance sensitive, but fewer moving parts / things that can go wrong). This also addresses the crash in https://crbug.com/1166077#c16 since the WasmValueObject instances now have a proper JSFunction in their maps' constructor_or_backpointer slot and are thus able to locate their creation context. Note that this doesn't generally address https://crbug.com/1166077 itself, but only the WasmValueObject case. Screenshot: https://imgur.com/kbd3bix.png Bug: chromium:1170282, chromium:1071432 Bug: chromium:1159402, chromium:1166077 Change-Id: Iae649cad155efd774cfb1f4eea8cf406e413c03a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692574Reviewed-by:
Philip Pfaffe <pfaffe@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72736}
-
- 12 Feb, 2021 5 commits
-
-
Ng Zhi An authored
This is a reland of a16add80. The fixes are adding disassembly for pcmpgtq and vpcmpgtq. While fixing also noticed a mistake in assembler for pcmpgtq, which flipped dst and src. Also realized that we don't detect SSE4.2, so adding that in. PS2 contains these changes. Original change's description: > [wasm-simd][ia32] Implement i64x2 signed compares > > The code sequence is exactly the same as x64. > > Bug: v8:11415 > Change-Id: I53ed2723eda29c0a250cff514372a3d45b203476 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2683495 > Reviewed-by: Bill Budge <bbudge@chromium.org> > Commit-Queue: Zhi An Ng <zhin@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72637} Bug: v8:11415 Change-Id: If6a18af2d7de20ac8ad38f94b6d0220769397194 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2688119Reviewed-by:
Bill Budge <bbudge@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72721}
-
Georg Neis authored
This reverts commit 87df0b7e (thus relands 42cd9eb7), with fixes for the discovered issues. Original change's description: > Revert "[compiler] Directly read PropertyCells" > > This reverts commit 42cd9eb7. > > Reason for revert: Clusterfuzz issues, e.g. > https://bugs.chromium.org/p/chromium/issues/detail?id=1176318 > > Original change's description: > > [compiler] Directly read PropertyCells > > > > Main changes: > > > > - Introduce a new broker data kind kBackgroundSerialized for objects > > that can be serialized in the background (when direct reads are on). > > (I'm planning to remove kPossiblyBackgroundSerialized in a followup, > > in favor of a dynamic choice of kSerialized or kBackgroundSerialized). > > - Make PropertyCell use that new kind. > > - Introduce a bottleneck in runtime code for changes to PropertyCells > > and make sure that a certain protocol is followed that allows > > concurrent reads from the background thread. > > - Improve interface of PropertyCell in various ways. > > > > Bug: v8:7790 > > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462 > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > > Commit-Queue: Georg Neis <neis@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#72586} > > TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org > > Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180 > Bug: v8:7790 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125 > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72619} Bug: v8:7790, chromium:1176509, chromium:1176318, chromium:1176504 Change-Id: Icaf285912bb948432a4a2d599cd174f6a5aa296e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685166Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72697}
-
Leszek Swirski authored
Currently we sometimes refer to baseline code or the baseline compiler by its codename (Sparkplug). The codename is fun, but we should be consistent and call things by one name or the other. Following the pattern of Ignition stuff being called "interpreter", we call Sparkplug "baseline", and leave the codename only in flags and variants. Bug: v8:11420 Change-Id: I432e5629518be7c7ad38b6acff024c91d4cfd6d3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2692186 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#72696}
-
Benedikt Meurer authored
Following up on https://crrev.com/c/2689185, this CL significantly simplifies the whole implementation of the stack trace capturing. Before this CL, capturing any stack trace (for the purpose of the API or Error.stack) would roughly work like this: 1. The CaptureStackTrace() function uses the StackFrameIterator to walk the system stack. For each native frame it uses the FrameSummary abstraction to get all (including potentially inlined) frames. For each of those it appends a record consisting of six elements to a FrameArray (this holds pointers to the actual closures and receivers). 2. Afterwards the FrameArray is shrinked to the required size, and a new FixedArray is allocated, and initialized with new StackTraceFrame objects where each holds a reference to the FrameArray, the index of the frame, and an initially uninitialized StackFrameInfo reference. This new FixedArray is then returned from CaptureStackTrace() and either stored on a message object or provided to the API as v8::StackTrace. The new approach removes a lot of the machinery in between and directly creates a FixedArray of StackFrameInfo objects in CaptureStackTrace(). These StackFrameInfo objects are directly exposed as v8::StackFrame on the public API, and they hold the six fields that were previously stored flat in the FrameArray. This not only avoids a lot of copying around of data and creation of temporary objects and handles, but most importantly unifies and simplifies the stack frame function inside StackFrameInfo, so you no longer need to wonder which function / object might be responsible for a certain API. There's still a lot of room for improvement. In particular we currently don't cache the source position for a given StackFrameInfo (or globally), but rather recompute it every time. This is still very fast, significantly faster than the previous approach. There are some notable (potentially user visible) changes: - The CallSite#GetPosition() method now consistently returns the Wasm module relative bytecode offset for all Wasm frames (previously it'd return the function relative bytecode offset for non-asm.js Wasm frames). - The column and line numbers returned from StackFrameInfo methods are consistently 1-based now, instead of sometimes being 0-based (Wasm) and sometimes being 1-based (JS and asm.js Wasm). The only potentially noticable difference is that for CallSite#GetLineNumber() no longer returns 0 for Wasm frames, but that was wrong and useless anyways. - CallSite#GetThis() would sometimes return the_hole, another bug flushed out by this CL. The CL also contains some other not noteworthy drive-by-cleanups. Fixed: chromium:1057211 Bug: chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: Iff12f6838a4d99080db8dd96bccc14440affc5a5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689183 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#72694}
-
Leszek Swirski authored
Sparkplug is a new baseline, non-optimising second-tier compiler, designed to fit in the compiler trade-off space between Ignition and TurboProp/TurboFan. Design doc: https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing Bug: v8:11420 Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72686}
-
- 11 Feb, 2021 2 commits
-
-
Santiago Aboy Solanes authored
Reasons: * We disabled it more than a year ago for all configs * Not easy to re-enable * Not compatible with pointer compression as-is * Not compatible with concurrent TP/TF as-is * No concrete plans to re-enable it Also remove Map's layout_descriptor since it was only used for double field unboxing. Bug: v8:11422 Change-Id: I9260906eac199213b3210712e9903f1ecf1d7979 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676637Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#72671}
-
Benedikt Meurer authored
For a long time, V8 had two distinct ways to capture and store a stack trace, one where we'd just collect and symbolize the information for the v8::StackTrace API (script id, name, line and colum information mostly), and one where V8 would also memorize the closures, receivers, and optionally the parameters of the stack frame, which we use for Error.stack and the non-standard CallSite APIs. Those two were often out of sync and suffered from various different issues. Eventually they were refactored into a single captureStackTrace() bottleneck that would produce a FrameArray. This CL is a logical continuation of the refactorings. It repairs a regression where we'd compute the method name (as part of the cached StackFrameInfo) even if we don't need them (as is the case for the inspector and any other use of the v8::StackTrace API). Everytime a method was invoked on StackTraceFrame, it'd call into StackTraceFrame::GetInfo(), which would lazily setup the StackFrameInfo like this: 1. Create a FrameArrayIterator and point it to the FrameArray at the index stored in the StackTraceFrame. 2. Invoke FrameArrayIterator::Frame(), which copies the information from the FrameArray into a temporary JSStackFrame, AsmJsStackFrame or WasmStackFrame C++ object, and use the StackFrameBase virtual methods to transfer all information to a newly created StackFrameInfo object. 3. Kill the link to the FrameArray and put a link to the StackFrameInfo object into the StackTraceFrame. This caching turned out to be extremely costly, since beyond other things, it'd always invoke JSStackFrame::GetMethodName(), which is extremely costly (the execution time is linear in the number of properties on the receiver and it's prototype chain). The cost was so high that several work-arounds had been added, which would avoid triggering the eager construction of the StackFrameInfo object (i.e. https://crrev.com/c/2080663, https://crrev.com/c/2550504 or https://crrev.com/c/2261736, but also https://crrev.com/c/1688927). This CL removes the StackFrameInfo caching completely, since neither the inspector nor Error.stack benefit from the caching at all. It's only the first part in a series of refactorings that will significantly reduce the complexity and overhead of the stack trace collection. Doc: https://bit.ly/2wkbuIy Bug: chromium:1057211, chromium:1077657, chromium:1069425, v8:8742 Bug: chromium:1127391, chromium:1098530, chromium:981541 Change-Id: I8edb8ff48b620eb3043ae51ab4ea27146ef0a5a2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2689185 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Yang Guo <yangguo@chromium.org> Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#72647}
-
- 10 Feb, 2021 3 commits
-
-
Daniel Clark authored
With top-level await, when Evaluate is performed on an already-evaluated synthetic module, Module::InnerEvaluate returns undefined. This breaks top-level await's assumption that the returned value is always a promise. In order to make SyntheticModule's behavior consistent with SourceTextModule, the top_level_capability field is moved up to Module and SyntheticModule::Evaluate places the promise returned from the host's evaluation steps in that field. Now SourceTextModule and SyntheticModule can share the same code to handle the case where the module is either kErrored or kEvaluated, so the code for this is moved up to Module. Thus, SyntheticModule is now guaranteed to return the promise from the evaluation steps even on subsequent Evaluate() calls. Unfortunately Node hasn't yet updated their EvaluationStepsCallback to return a Promise, so we can't yet assume that the returned value is a Promise without breaking Node. So, this change also adds a clause to check for this condition and create a new resolved Promise if one was not provided by the callback steps. This could eventually be removed once Node's callback steps are updated for top-level await. Change-Id: I2d6ae918abfeba9e3a757838502d4df92946edaa Bug: v8:11398 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2673794Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72629}
-
Seth Brenith authored
Previously in https://chromium-review.googlesource.com/c/v8/v8/+/2545573 I updated BasicBlockInstrumentor to use 64-bit floating-point values rather than 32-bit integers, so that it could never overflow. However, I've now learned that some builtins (particularly RecordWrite) are not allowed to use floating-point registers, and so running with basic block instrumentation enabled could produce incorrect results. This change switches back to 32-bit integers, but adds saturation logic. Bug: chromium:1170776 Change-Id: Icbd93919fb05f50d615ec479263142addbe15c9e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685617Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72626}
-
Georg Neis authored
This reverts commit 42cd9eb7. Reason for revert: Clusterfuzz issues, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1176318 Original change's description: > [compiler] Directly read PropertyCells > > Main changes: > > - Introduce a new broker data kind kBackgroundSerialized for objects > that can be serialized in the background (when direct reads are on). > (I'm planning to remove kPossiblyBackgroundSerialized in a followup, > in favor of a dynamic choice of kSerialized or kBackgroundSerialized). > - Make PropertyCell use that new kind. > - Introduce a bottleneck in runtime code for changes to PropertyCells > and make sure that a certain protocol is followed that allows > concurrent reads from the background thread. > - Improve interface of PropertyCell in various ways. > > Bug: v8:7790 > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72586} TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180 Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72619}
-
- 09 Feb, 2021 5 commits
-
-
Ng Zhi An authored
Bug: v8:11347,v8:11348,chromium:1174498 Change-Id: I9afaacefcab55a6d7eb48f6e9d1848b714f64eb6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2666147Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72603}
-
Brice Dobry authored
This very large changeset adds support for RISC-V. Bug: v8:10991 Change-Id: Ic997c94cc12bba6881bc208e66526f423dd0679c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2571344 Commit-Queue: Brice Dobry <brice.dobry@futurewei.com> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#72598}
-
Georg Neis authored
Main changes: - Introduce a new broker data kind kBackgroundSerialized for objects that can be serialized in the background (when direct reads are on). (I'm planning to remove kPossiblyBackgroundSerialized in a followup, in favor of a dynamic choice of kSerialized or kBackgroundSerialized). - Make PropertyCell use that new kind. - Introduce a bottleneck in runtime code for changes to PropertyCells and make sure that a certain protocol is followed that allows concurrent reads from the background thread. - Improve interface of PropertyCell in various ways. Bug: v8:7790 Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72586}
-
Frank Emrich authored
This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL contains most of the boilerplate code for introducing a new instance type. Bug: v8:11388 Change-Id: Id263b8138a8ce4b465fb28d968223d2e1aaf05a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672030Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#72582}
-
Benedikt Meurer authored
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now represented as objects instead of holding the (primitive) values directly, and SIMD128 values are no longer represented as Uint8Arrays. The DWARF extension has been prepared for this breaking change. The new `WasmValue` comes with `type` and `value` properties that hold its contents. The motivation here is that this is a more extensible approach. In case of SIMD128, the `value` property holds the canonical string representation, which has the additional advantage that these values can be compared with `===` (and `==`). This partially reverts https://crrev.com/c/2614428, the main difference here being that WasmValue is now a proper JSObject that can be exposed on the DebugEvaluate proxy API. Screenshot: https://imgur.com/rcahNKM.png Bug: chromium:1170282, chromium:1071432, chromium:1159402 Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384Reviewed-by:
Philip Pfaffe <pfaffe@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72570}
-
- 04 Feb, 2021 2 commits
-
-
Ng Zhi An authored
Implement these 6 instructions: - f64x2.convert_low_i32x4_s - f64x2.convert_low_i32x4_u - i32x4.trunc_sat_f64x2_s_zero - i32x4.trunc_sat_f64x2_u_zero - f32x4.demote_f64x2_zero - f64x2.promote_low_f32x4 The code sequences are exactly the same as on x64. Needed to add some more instructions, and we don't have macro lists for these instructions yet, so individually define them for now. We can factor them into lists in a future change. Bug: v8:11265 Change-Id: I606e1226201e3c5ecdc7e3f611315437e917d77c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2668913Reviewed-by:
Deepti Gandluri <gdeepti@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/master@{#72535}
-
Jakob Gruber authored
... and mark it as never-serialized wrt turbofan serialization. Until this CL, the JSRegExp type was used as both for plain user-visible regexp objects, and for internal regexp boilerplate descriptions. Boilerplates are special: they are never exposed to the user, they are only referenced from the feedback vector, they are immutable. To clarify this distinction, this CL introduces a dedicated struct type RegExpBoilerplateDescription to hold the regexp boilerplate description. This makes Turbofan serialization simpler: boilerplates can be accessed through direct reads since they are immutable. TF has no special requirements on JSRegExp objects (it never reads into these objects) and thus serializing only the references as a JSObjectRef is fine. Bug: v8:7790 Change-Id: I33b337fcfcf861a02bc6be6d0c6311d07cf05718 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2656257Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#72522}
-