- 06 Dec, 2021 1 commit
-
-
Igor Sheludko authored
In particular * use variadic templates in BodyDescriptorApply(), * ensure all the relevant classes have BodyDescriptor definition, * ensure "objects-body-descriptors[-inl].h" headers are included only where necessary. Bug: v8:12425 Change-Id: I7a95ed94bf62952e3d22d419d4a65ad2fe959d57 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3312273Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78242}
-
- 25 Jun, 2021 1 commit
-
-
John Xu authored
These changes are found after Cobalt rebased to V8 v8.8. Most changes are grouped into their own CLs and here are the rest. - Replace raw printf with PrintF - Include Starboard as a platform for some implementations - Add some missing headers. This is probably because Cobalt does not compile all of V8 sources so some missing headers are only exposed when compiling Cobalt. Change-Id: Idf1512f57c37c8a63f79b1cf4ffc1da5d08421e2 Bug: v8:10927 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2966197 Auto-Submit: John Xu <johnx@google.com> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: John Xu <johnx@google.com> Cr-Commit-Position: refs/heads/master@{#75376}
-
- 28 Oct, 2020 1 commit
-
-
Tobias Tebbi authored
This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
-
- 18 Mar, 2020 1 commit
-
-
Tobias Tebbi authored
In the runtime, we always had a convention to use int-typed accessors for Smi fields. For Torque-generated classes, we kept them Smi-typed but then added int wrappers around that. This CL makes Torque generate int-typed accessors directly, removing the need for these wrappers. TBR=hpayer@chromium.org Bug: v8:7793 Change-Id: I348e1d96295c9676fafda32b7d49088848527f89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2106210 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#66760}
-
- 09 Jan, 2020 1 commit
-
-
Seth Brenith authored
This change updates CachedTemplateObjectMap, BreakPointInfo, and BreakPoint to inherit directly from Struct rather than Tuple2 or Tuple3. It also removes Tuple3 because nothing else used Tuple3. By avoiding tuple types, we get various benefits that Torque can provide: - stricter debug verifier functions - accessors, cast functions, and printers are generated - BreakPoint and BreakPointInfo have different instance types, so you can tell them apart at runtime or in a debugger Change-Id: I9367bc08c6dea55d659fd610f9f6105fd61c907a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988793Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#65668}
-
- 29 Aug, 2019 1 commit
-
-
Seth Brenith authored
This patch is mostly mechanical. A few changes in implementation-visitor.cc might be worth mentioning: - Don't generate both field offset macros and class definitions for the same class. This was mostly just to keep me from forgetting to remove the DEFINE_FIELD_OFFSET_CONSTANTS part when converting classes, but also helpfully flagged that FixedArrayBase wasn't using the generated class that it requested. - Generate forward declarations for all tq-defined classes in internal-class-definitions-tq.h. This is helpful for making things compile when classes have fields of other class types. - When generating accessors for union types, use the nearest class type that contains the entire union rather than plain Object. This is important for compile-time type safety. It also required a few minor fixes elsewhere (isolate.cc, modules.cc, scope-info.cc, source-text-module.cc, and a correction of the field types in CallHandlerInfo to match how they're set in api.cc). Change-Id: I3b9280e30779ce57fb9f3629eecfec898e26d708 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1774976Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#63458}
-
- 08 Jul, 2019 1 commit
-
-
Georg Neis authored
Change-Id: I9285052dfe21df8e0eaf0e0493458532f82504ae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687421Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Auto-Submit: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#62546}
-
- 20 May, 2019 1 commit
-
-
Suraj Sharma authored
Bug: v8:8952 Change-Id: I36ee0d6793a4a9715360c155636f6e19db2119bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1616015 Commit-Queue: Suraj Sharma <surshar@microsoft.com> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Simon Zünd <szuend@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#61673}
-
- 25 Feb, 2019 1 commit
-
-
Ross McIlroy authored
Template objects should be cached after they are first created and reused on subsiquent calls to tag functions. Currently these cached objects are stored on the feedback vector, which has appropriate lifetime, however with bytecode flushing the feedback vector could be cleared when the bytecode is flushed, causing the template object to be dropped. In order to retain the cached template objects in the face of bytecode flushing, this CL adds a weakmap for each native context that is (weakly) keyed by shared function info, and holds a linked list of cached template objects associated with that shared function info, indexed by feedback vector slot id. Misses will check this weakmap, and if no entry is found, a new template object is created and added into this weakmap alongside the feedback vector. BUG=v8:8799,v8:8799,v8:8395 Change-Id: Ia95d5cfc394ce58dc9fe6a1e49780f05299acc17 Reviewed-on: https://chromium-review.googlesource.com/c/1477746 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#59818}
-
- 14 Feb, 2019 1 commit
-
-
Sigurd Schneider authored
Change-Id: Ic60f74a60480ea4a74e039c5c87e8c1995e60453 Bug: v8:8834 Reviewed-on: https://chromium-review.googlesource.com/c/1473032Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#59603}
-
- 09 Jan, 2019 1 commit
-
-
Jakob Kummerow authored
The incremental migration required several pairs of functionally equivalent macros. This patch consolidates everything onto the respective new version and drops the obsolete versions. Bug: v8:3770 Change-Id: I4fb05ff223e8250c83a13f46840810b0893f410b Reviewed-on: https://chromium-review.googlesource.com/c/1398223Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Andreas Haas <ahaas@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58659}
-
- 17 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
Tuple2 and subclasses: EnumCache, SourcePositionTableWithFrameCache, TemplateObjectDescription Bug: v8:3770 Change-Id: Icff0860a04445dda542119834ef9866167ba2263 Reviewed-on: https://chromium-review.googlesource.com/c/1377772 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#58287}
-
- 14 Dec, 2018 1 commit
-
-
Jakob Kummerow authored
along with subclasses: Tuple2, Tuple3, FeedbackCell, AccessorPair. The latter two can be separated out later if desired. Bug: v8:5402 Change-Id: I4e1a6d2621cc6f96b5da208cff0da7cd5de91672 Reviewed-on: https://chromium-review.googlesource.com/c/1371038Reviewed-by: Marja Hölttä <marja@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#58251}
-
- 25 Nov, 2018 1 commit
-
-
Jakob Kummerow authored
Removing the temporarily duplicated classes FixedArrayPtr and FixedArrayBasePtr. Bug: v8:3770 Change-Id: I056ad74ff69593e9f134ef5c976766812c4d9275 Reviewed-on: https://chromium-review.googlesource.com/c/1345913 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Ben Titzer <titzer@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/master@{#57807}
-
- 20 Jun, 2018 1 commit
-
-
Leszek Swirski authored
Bug: v8:7786 Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng Change-Id: If9904fe8feb9b4e157d42d6e84f1aa263abcc8b7 Reviewed-on: https://chromium-review.googlesource.com/1106160 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Dan Elphick <delphick@chromium.org> Cr-Commit-Position: refs/heads/master@{#53882}
-
- 12 Feb, 2018 1 commit
-
-
Caitlin Potter authored
Implements the change outlined in https://github.com/tc39/ecma262/pull/890, which has been ratified and pulled into the specification. In particular, template callsite objects are no longer kept in a global, eternal Map, but are instead associated with their callsite, which can be collected. This prevents a memory leak incurred by TaggedTemplate calls. Changes, summarized: - Remove the TemplateMap and TemplateMapShape objects, instead caching template objects in the feedback vector. - Remove the `hash` member of TemplateObjectDescriptor, and the Equals method (used by TemplateMap) - Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures that a new feedback vector is always created for eval() containing tagged templates, even when the CompilationCache is used. - GetTemplateObject bytecode now takes a feedback index, and only calls into the runtime if the feedback is Smi::kZero (uninitialized). BUG=v8:3230, v8:2891 R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org, rmcilroy@chromium.org Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423 Reviewed-on: https://chromium-review.googlesource.com/624564 Commit-Queue: Caitlin Potter <caitp@igalia.com> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#51248}
-
- 22 Sep, 2017 1 commit
-
-
Benedikt Meurer authored
Tagged templates were previously desugared during parsing using some combination of runtime support written in JavaScript and C++, which prevented some optimizations from happening, namely the constant folding of the template object in TurboFan optimized code. This CL adds a new bytecode GetTemplateObject (with a corresponding GetTemplateObject AST node), which represents the abstract operation in the ES6 specification and allows TurboFan to simply constant-fold template objects at compile time (which is explicitly supported by the specification). This also pays down some technical debt by removing the template.js runtime support and therefore should reduce the size of the native context (snapshot) a bit. With this change in-place the ES6 version microbenchmark in the referenced tracking bug is now faster than the transpiled Babel code, it goes from templateStringTagES5: 4552 ms. templateStringTagES6: 14185 ms. templateStringTagBabel: 7626 ms. to templateStringTagES5: 4515 ms. templateStringTagES6: 7491 ms. templateStringTagBabel: 7639 ms. which corresponds to a solid 45% reduction in execution time. With some further optimizations the ES6 version should be able to outperform the ES5 version. This micro-benchmark should be fairly representative of the six-speed-templatestringtag-es6 benchmark, and as such that benchmark should also improve by around 50%. Bug: v8:6819,v8:6820 Tbr: mlippautz@chromium.org Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc Reviewed-on: https://chromium-review.googlesource.com/677462Reviewed-by: Mythri Alle <mythria@chromium.org> Reviewed-by: Caitlin Potter <caitp@igalia.com> Reviewed-by: Adam Klein <adamk@chromium.org> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#48126}
-