- 23 Jul, 2020 1 commit
-
-
Jakob Gruber authored
A small step for a JSFunction, one giant leap for V8. Tbr: clemensb@chromium.org Bug: v8:8888 Change-Id: I968bb819763994ec611cde7e502adea30339a387 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315979 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#69018}
-
- 10 Jul, 2020 1 commit
-
-
Leszek Swirski authored
Rather than marking deleted GlobalDictionary entries with a "The Hole" valued PropertyCell, we now remove those PropertyCells entirely and use the standard HashTable deleted item marker (also the Hole). This comes with several simplifications: 1) We no longer need a customizable IsKey method on HastTable shapes, which was only used by GlobalDictionary to mark "The Hole" cells as not real keys, 2) We can get rid of IsLive/IsKey from the Shape entirely, and define it directly in the HashTable, which will also allow us (in the future) to encourage caching of "undefined" and "Hole" where used for IsKey checks, 3) PropertyCell invalidation doesn't necessarily have to allocate a new replacement cell (specifically, on deletion), nor does it have to deal with cells that contain the Hole, 4) kNeedsHoleCheck is renamed to kMatchNeedsHoleCheck (to be explicit that this is only needed to guard IsMatch, which may do an indentity comparison and thus not need the HoleCheck guard). It's also moved out of BaseShape and into the various shapes that define IsMatch, to make them more explicitly think about the value, 5) Modified some while loops into for loops to allow clearer use of "continue" on successful hole checks. Change-Id: If591cbb6b49d59726bdc615413aba4f78fd64632 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2292230 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#68807}
-
- 02 Jul, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Bug: v8:7790 Change-Id: I1b9116529575f56c890f93488a0ffdebfdfe5763 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2260873 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68649}
-
- 10 Jun, 2020 1 commit
-
-
Georg Neis authored
Foozie came up with a mind-boggling example hitting a similarly mind-boggling bug: object construction (JSObject::New) wants to create the constructor's function initial map (JSFunction::GetDerivedMap -> JSFunction::EnsureHasInitialMap). To do so, it calls JSFunction::CalculateExpectedNofProperties. This harmless sounding function triggers compilation of the function. Since we're running with --always-opt, this is an optimizing compilation. Turbofan ends up depending on the function's "prototype" property, for which it wants to create the initial map so that it can install the code dependency. That is, EnsureHasInitialMap is reentered. At this point there is no further compilation attempt because the bytecode now exists. The initial map is created and installed on the function, and TF records the code dependency on that map. When CalculateExpectedNofProperties returns control to the outer EnsureHasInitialMap, yet another initial map is created and set on the function, forgetting the previous one and thus the code dependency. I'm not sure if this bug can only be observed with --always-opt. The fix is general. Bug: chromium:1092011 Change-Id: I8b972748e49b9eb8f06fa17ea9ca037de2bd7532 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2238570Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#68292}
-
- 03 Jun, 2020 1 commit
-
-
Mythri A authored
This is a followup of the cl [1] that fixes a bug where bytecode was getting flushed when allocating feedback vector. The fix added IsCompiledScope before allocating a new feedback vector. We now pass IsCompiledScope to JSFunction::EnsureFeedbackVector. This makes it explicit that EnsureFeedbackVector expects a function that is compiled and the bytecode shouldn't be flushed during the allocation.Also adds a test. [1] https://chromium-review.googlesource.com/c/v8/v8/+/2218066 Bug: v8:10560 Change-Id: I552c449a57555dffa625b2e4efa04c2c276fc0b4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2222347 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Cr-Commit-Position: refs/heads/master@{#68142}
-
- 15 May, 2020 1 commit
-
-
Bill Budge authored
- Ports FastFunctionPrototypeBind and FunctionPrototypeHasInstance to torque. Bug: v8:9891 Change-Id: Iaebaf3c6025907a1b7310c4e08200b4855c7ca6b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2188929 Commit-Queue: Bill Budge <bbudge@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#67832}
-
- 27 Apr, 2020 1 commit
-
-
Jakob Gruber authored
This reverts commit 14ebea15. Reason for revert: CountUsage() can't be called without a C entry frame. Note this counter was never hooked up in chromium. Besides removing the problematic CountUsage() call, this CL also makes the call path more robust against similar future issues by adding {gc,handle,js} disallow scopes. Original change's description: > Add counter to track `Date::getTimezoneOffset()`. > > Bug: chromium:915620 > Change-Id: I75579080098632639b125b2252b3ab9615c7ea95 > Reviewed-on: https://chromium-review.googlesource.com/c/1379876 > Reviewed-by: Yang Guo <yangguo@chromium.org> > Commit-Queue: Mike West <mkwst@chromium.org> > Cr-Commit-Position: refs/heads/master@{#58306} TBR=yangguo@chromium.org,mkwst@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Tbr: ulan@chromium.org Bug: chromium:915620,v8:10460 Change-Id: I2dd2e14947fe527de24ea644b4b33897f437a119 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2165790 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#67399}
-
- 24 Apr, 2020 2 commits
-
-
Timothy Gu authored
This is a reland of 29c1eab9 Original change's description: > [builtins] Clean up the use of class_name / ES5 [[Class]] > > Before ES2015, the ES spec had a [[Class]] internal slot for all > objects, which Object.prototype.toString() would use to figure the > returned string. Post-ES2015, the [[Class]] slot was removed in spec for > all objects, with the @@toStringTag well-known symbol the proper way to > change Object.prototype.toString() output. > > At the time, spec-identical handling without the use of [[Class]] was > implemented in V8 for all objects other than API objects, where issues > with the Web IDL spec [1] prevented Blink, and hence V8, to totally > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting > @@toStringTag on API class prototypes to manage the > Object.prototype.toString() output, so the legacy [[Class]] handling in > V8 has not been necessary for the past couple of years. > > This CL removes the remaining legacy [[Class]] handling in > Object.prototype.toString(), JSReceiver::class_name(), and > GetConstructorName(). However, it does not remove the class_name field > in FunctionTemplateInfo, as it is still used for the `name` property of > created functions. > > This CL also cleans up other places in the codebase that still reference > [[Class]]. > > This change should have minimal impact on web-compatibility. For the > change to be observable, a script must do one of the following: > > 1. delete APIConstructor.prototype[Symbol.toStringTag]; > 2. Object.setPrototypeOf(apiObject, somethingElse); > > Before this CL, these changes will not change the apiObject.toString() > output. But after this CL, they will make apiObject.toString() show > "[object Object]" (in the first case) or the @@toStringTag of the other > prototype (in the latter case). > > However, both are deemed unlikely. @@toStringTag is not well-known > feature of JavaScript, nor does it get tampered much on API > constructors. In the second case, setting the prototype of an API object > would effectly render the object useless, as all its methods (including > property getters/setters) would no longer be accessible. > > Currently, @@toStringTag-based API object branding is not yet > implemented by other browsers. This V8 bug in particular has been an > impediment to standardizing toString behavior. Fixing this bug will > unblock [3] and lead to a better Web IDL spec, and better toString() > compatibility for all. > > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4 > [3]: https://github.com/heycam/webidl/pull/357 > > Bug: chromium:793406 > Cq-Include-Trybots: luci.chromium.try:linux-rel > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996 > Commit-Queue: Timothy Gu <timothygu@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67327} Bug: chromium:793406 Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1 Cq-Include-Trybots: luci.chromium.try:linux-rel Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881 Auto-Submit: Timothy Gu <timothygu@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67361}
-
Bill Budge authored
This reverts commit 29c1eab9. Reason for revert: Causes Blink test failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222 Original change's description: > [builtins] Clean up the use of class_name / ES5 [[Class]] > > Before ES2015, the ES spec had a [[Class]] internal slot for all > objects, which Object.prototype.toString() would use to figure the > returned string. Post-ES2015, the [[Class]] slot was removed in spec for > all objects, with the @@toStringTag well-known symbol the proper way to > change Object.prototype.toString() output. > > At the time, spec-identical handling without the use of [[Class]] was > implemented in V8 for all objects other than API objects, where issues > with the Web IDL spec [1] prevented Blink, and hence V8, to totally > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting > @@toStringTag on API class prototypes to manage the > Object.prototype.toString() output, so the legacy [[Class]] handling in > V8 has not been necessary for the past couple of years. > > This CL removes the remaining legacy [[Class]] handling in > Object.prototype.toString(), JSReceiver::class_name(), and > GetConstructorName(). However, it does not remove the class_name field > in FunctionTemplateInfo, as it is still used for the `name` property of > created functions. > > This CL also cleans up other places in the codebase that still reference > [[Class]]. > > This change should have minimal impact on web-compatibility. For the > change to be observable, a script must do one of the following: > > 1. delete APIConstructor.prototype[Symbol.toStringTag]; > 2. Object.setPrototypeOf(apiObject, somethingElse); > > Before this CL, these changes will not change the apiObject.toString() > output. But after this CL, they will make apiObject.toString() show > "[object Object]" (in the first case) or the @@toStringTag of the other > prototype (in the latter case). > > However, both are deemed unlikely. @@toStringTag is not well-known > feature of JavaScript, nor does it get tampered much on API > constructors. In the second case, setting the prototype of an API object > would effectly render the object useless, as all its methods (including > property getters/setters) would no longer be accessible. > > Currently, @@toStringTag-based API object branding is not yet > implemented by other browsers. This V8 bug in particular has been an > impediment to standardizing toString behavior. Fixing this bug will > unblock [3] and lead to a better Web IDL spec, and better toString() > compatibility for all. > > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4 > [3]: https://github.com/heycam/webidl/pull/357 > > Bug: chromium:793406 > Cq-Include-Trybots: luci.chromium.try:linux-rel > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996 > Commit-Queue: Timothy Gu <timothygu@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#67327} TBR=verwaest@chromium.org,timothygu@chromium.org Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: chromium:793406 Cq-Include-Trybots: luci.chromium.try:linux-rel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956Reviewed-by: Bill Budge <bbudge@chromium.org> Commit-Queue: Bill Budge <bbudge@chromium.org> Cr-Commit-Position: refs/heads/master@{#67349}
-
- 23 Apr, 2020 1 commit
-
-
Timothy Gu authored
Before ES2015, the ES spec had a [[Class]] internal slot for all objects, which Object.prototype.toString() would use to figure the returned string. Post-ES2015, the [[Class]] slot was removed in spec for all objects, with the @@toStringTag well-known symbol the proper way to change Object.prototype.toString() output. At the time, spec-identical handling without the use of [[Class]] was implemented in V8 for all objects other than API objects, where issues with the Web IDL spec [1] prevented Blink, and hence V8, to totally migrate to @@toStringTag. However, since 2016 [2] Blink has been setting @@toStringTag on API class prototypes to manage the Object.prototype.toString() output, so the legacy [[Class]] handling in V8 has not been necessary for the past couple of years. This CL removes the remaining legacy [[Class]] handling in Object.prototype.toString(), JSReceiver::class_name(), and GetConstructorName(). However, it does not remove the class_name field in FunctionTemplateInfo, as it is still used for the `name` property of created functions. This CL also cleans up other places in the codebase that still reference [[Class]]. This change should have minimal impact on web-compatibility. For the change to be observable, a script must do one of the following: 1. delete APIConstructor.prototype[Symbol.toStringTag]; 2. Object.setPrototypeOf(apiObject, somethingElse); Before this CL, these changes will not change the apiObject.toString() output. But after this CL, they will make apiObject.toString() show "[object Object]" (in the first case) or the @@toStringTag of the other prototype (in the latter case). However, both are deemed unlikely. @@toStringTag is not well-known feature of JavaScript, nor does it get tampered much on API constructors. In the second case, setting the prototype of an API object would effectly render the object useless, as all its methods (including property getters/setters) would no longer be accessible. Currently, @@toStringTag-based API object branding is not yet implemented by other browsers. This V8 bug in particular has been an impediment to standardizing toString behavior. Fixing this bug will unblock [3] and lead to a better Web IDL spec, and better toString() compatibility for all. [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244 [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4 [3]: https://github.com/heycam/webidl/pull/357 Bug: chromium:793406 Cq-Include-Trybots: luci.chromium.try:linux-rel Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996 Commit-Queue: Timothy Gu <timothygu@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#67327}
-
- 20 Mar, 2020 1 commit
-
-
Victor Gomes authored
Bug: v8:10201 Change-Id: I72cbe15912395b9b06ffdccce935abae6e7a050e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2093508Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66808}
-
- 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}
-
- 26 Feb, 2020 1 commit
-
-
Victor Gomes authored
This adds static types to the argument class that accesss the arguments in the stack. kRuntime arguments are used by runtime functions and kJS arguments are used to access the JS stack (eg. builtins). The distinction allows the reversal of arguments in the JS stack without changing the runtime arguments order. Bug: v8:10201 Change-Id: I7c08164d53c4071c7910836fa733dee8ff7fa680 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066985 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66470}
-
- 20 Jan, 2020 1 commit
-
-
Mythri A authored
When bytecode is flushed we also want to flush the feedback vectors to save memory. There was a bug in this code and we flushed ClosureFeedbackCellArray too. Flushing ClosureFeedbackCellArrays causes the closures created by this function before and after the bytecode flush to have different feedback cells and hence different feedback vectors. This cl fixes it so we only flush feedback vectors on a bytecode flush. Also this cl pretenures ClosureFeedbackCellArrays. Only FeedbackCells and FeedbackVectors can contain ClosureFeedbackCellArrays which are pretenured, so it is better to pretenure ClosureFeedbackCellArrays as well. Bug: chromium:1031479 Change-Id: I7831441a95420b9e5711f4143461f1eb7fa1616a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1980582 Commit-Queue: Mythri Alle <mythria@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Cr-Commit-Position: refs/heads/master@{#65866}
-
- 10 Jan, 2020 1 commit
-
-
Sigurd Schneider authored
This CL adds a mode to the JSReceiver::GetDataProperty that does not box unboxed double fields. This method can be used to fix a critical bug in the heap snapshot generator that currently causes a GC in a place where no GC should be caused. Change-Id: If195f6811090281d364e3c8fa221a1d6b96bcd80 Bug: v8:9993 Fixed: chromium:1038490 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993286 Commit-Queue: Sigurd Schneider <sigurds@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65694}
-
- 09 Jan, 2020 1 commit
-
-
Ulan Degenbaev authored
This changes the marking worklist draining for the main thread marker and the concurrent marker to use the following algorithm in per-context mode: 1) Pop an object from the marking worklist. 2) Try to infer the native context that owns the objects. This is done using a new NativeContextInferrer class. 3) If the inference is successful, then change the active marking worklist to the worklist of the inferred native context. 4) Otherwise, keep the current active marking worklist. 5) Visit the object. Newly discovered objects will be pushed onto the active marking worklist. 6) Account the object size for the native context corresponding to the active marking worklist. This is done using a new NativeContextStats class. The main property of the algorithm is that each object for which we couldn't infer the native context is either attributed to the native context retaining it or is not attributed to any native context. Bug: chromium:973627 Change-Id: Ide4ab992275d115279f971d89ace657f4c05e176 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1981491 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/master@{#65663}
-
- 13 Dec, 2019 1 commit
-
-
Michael Starzinger authored
R=clemensb@chromium.org Change-Id: Ibd6790a222590fd4dce9f918219a19f01c2e1e0f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960293Reviewed-by: Clemens Backes <clemensb@chromium.org> Reviewed-by: Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#65439}
-
- 04 Dec, 2019 1 commit
-
-
Joyee Cheung authored
This patch implements inspector support for private instance methods: - Previously to implement brand checking for instances with private instance methods we store the brand both as the value with the brand itself as the key in the stances. Now we make the value the context associated with the class instead. - To retrieve the private instance methods and accessors from the instances at runtime, we look into the contexts stored with the brands, and analyze the scope info to get the names as well as context slot indices of them. - This patch extends the `PrivatePropertyDescriptor` in the inspector protocol to include optional `get` and `set` fields, and make the `value` field optional (similar to `PropertyDescriptor`s). Private fields or private instance methods are returned in the `value` field while private accessors are returned in the `get` and/or `set` field. Property previews for the instaces containing private instance methods and accessors are also updated similarly, although no additional protocol change is necessary since the `PropertyPreview` type can already be used to display accessors. Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit Bug: v8:9839, v8:8330 Change-Id: If37090bd23833a18f75deb1249ca5c4405ca2bf2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1934407 Commit-Queue: Joyee Cheung <joyee@igalia.com> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#65337}
-
- 27 Nov, 2019 1 commit
-
-
Leszek Swirski authored
To indicate that the Isolate* in getters might not be a "real" isolate, but rather a calculated one from GetIsolateForPtrCompr only used for calculating the isolate root, make that function return a const Isolate* and change field getters, Object::IsFoo predicates, and related functions to all take a const Isolate* instead of an Isolate* With this change, we can slightly more confidently use Objects that are in OffThreadSpace, without having to worry too much about having an Isolate* floating around that could accidentally be used. This is a slight abuse of const semantics, but it allows implicit conversion from Isolate* arguments to the const Isolate* parameter. Bug: v8:7703 Bug: chromium:1011762 Change-Id: I54d4a65d2299477195f4d754cabe64ce34fdaa4c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1939455 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65199}
-
- 21 Nov, 2019 1 commit
-
-
Tobias Tebbi authored
This introduces a new keyword "shape" in addition to "class", which allows the definition of a type that extends a JSObject subclass and specifies one or several maps with statically known in-object properties. Differences compared to normal classes: - Shapes are transient since they specify maps instead of instance types. - Shapes have a known size. - Fields of shapes are always in-object properties. In particular, this means that their offset is after kHeaderSize. - It's forbidden to inherited from shapes. - Since shapes usually specify NativeContext-dependent maps, it's not possible to write runtime type-checks for them. Thus this CL avoids mapping them to their own TNode type, as the CAST macro won't work properly. We had runtime-checks for some of them nevertheless, some of them scarily confusing like IsJSSloppyArgumentsObject, that actually just checked the instance type. Drive-by cleanups and simplifications: - Allow subclassing from non-abstract classes and remove @dirtyInstantiatedAbstractClass. This attribute stems from a mis- conception of how instance types work, and with this change it ceases to have semantic influence. - Replace the existing JSArgumentsObject subclasses into two shapes. JSArgumentsObjectWithLength had to be removed since shapes don't support subclassing. - Place kHeaderSize correctly for objects with indexed fields. Design doc: https://docs.google.com/document/d/1zPy2ZYfNFjeEuw6Mz3YJA-GaPGbdcSYam3SrS7ETzRU Bug: v8:8944 Change-Id: Iabf185ccd27d0900e0890539a7fe9eaa8bf2d50e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917140 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#65108}
-
- 20 Nov, 2019 1 commit
-
-
Jakob Kummerow authored
They have to be in sync, so this patch updates both systems. Bug: v8:4153 Change-Id: I09252e41a710e79f823fe6818c1c6c0038faeb31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903434Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Georg Neis <neis@chromium.org> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/master@{#65078}
-
- 18 Nov, 2019 1 commit
-
-
Tobias Tebbi authored
For many subclasses of JSObject, we used kSize instead of kHeaderSize even though they can contain in-object properties. In fact, kSize was very much used as the header size, as can be seen in many examples in this CL. This change is a preparation for a for a cleanup of how Torque generates field offsets. TBR=hpayer@chromium.org Change-Id: I350e996057cd66c427381334080f8ac93de88597 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1917141 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#65013}
-
- 16 Oct, 2019 1 commit
-
-
Jakob Kummerow authored
for "entries", i.e. indices into the backing store (as opposed to "public indices" going into the hash function). This improves consistency and compiler-enforced type safety; no change in behavior is intended. Change-Id: I25e57e3ddcf18a406e2dfbd66786b6980c4e9615 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852768 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Cr-Commit-Position: refs/heads/master@{#64317}
-
- 11 Oct, 2019 2 commits
-
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit Changes from the design doc: - Changed to use 'class' declarations rather than 'type' declarations for things that need instance types but whose layout is not known to Torque. These declarations end with a semicolon rather than having a full set of methods and fields surrounded by {}. If the class's name should not be treated as a class name in generated output (because it's actually a template, or doesn't exist at all), we use the standard 'generates' clause to declare the most appropriate C++ class. - Removed @instanceTypeName. - @highestInstanceType became @highestInstanceTypeWithinParentClassRange to indicate a semantic change: it no longer denotes the highest instance type globally, but only within the range of values for its immediate parent class. This lets us use it for Oddball, which is expected to be the highest primitive type. - Added new abstract classes JSCustomElementsObject and JSSpecialObject to help with some range checks. - Added @lowestInstanceTypeWithinParentClassRange so we can move the new classes JSCustomElementsObject and JSSpecialObject to the beginning of the JSObject range. This seems like the least-brittle way to establish ranges that also include JSProxy (and these ranges are verified with static assertions in instance-type.h). - Renamed @instanceTypeValue to @apiExposedInstanceTypeValue. - Renamed @instanceTypeFlags to @reserveBitsInInstanceType. This change introduces the new annotations and adds the ability for Torque to assign instance types that satisfy those annotations. Torque now emits two new macros: - TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the InstanceType enumeration - TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String parts of INSTANCE_TYPE_LIST The design document mentions a couple of other macro lists that could easily be replaced, but I'd like to defer those to a subsequent checkin because this one is already pretty large. Bug: v8:7793 Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64258}
-
Jakob Kummerow authored
This is for consistency and compiler-enforced type safety. No change in behavior intended. Change-Id: I31467832ba6c63fd5f97df9fee6221559b283d67 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1852766 Commit-Queue: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#64244}
-
- 09 Oct, 2019 1 commit
-
-
Seth Brenith authored
In preparation for allowing Torque to generate the list of instance types, I'd like to make the rules a bit more consistent for how instance types are spelled. This CL is my proposal for a system where every non-String instance type name is exactly equal to calling CapifyStringWithUnderscores on the corresponding class name and appending "_TYPE". This change is almost all find&replace; the only manual changes are in: - src/objects/instance-type.h - src/torque/utils.cc - tools/gen-postmortem-metadata.py This change is in response to the review comment https://chromium-review.googlesource.com/c/v8/v8/+/1757094/25/src/builtins/base.tq#132 Change-Id: Ife3857292669f54931708e934398b2684e60bea5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814888 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/master@{#64199}
-
- 07 Oct, 2019 1 commit
-
-
Seth Brenith authored
Just mechanical conversion to remove boilerplate code. When .tq and .h files didn't agree on what a field is named, I used the name from the .h file. In a couple of cases the generated accessor became slightly more specific (HeapObject instead of Object), and I had to update the code that uses those accessors accordingly. Change-Id: Ie3af1590e3889887b167c9d045b07860b01f7d15 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776479Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#64142}
-
- 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}
-
- 28 Aug, 2019 1 commit
-
-
Z Nguyen-Huu authored
Currently the backing store and elements kind might not aligned aka backing store can be dictionary where elements kind is frozen/sealed element kinds or the other way around. The reason is that Object.preventExtensions change elements kind to DICTIONARY while Object.seal/freeze change elements kind to SEALED/FROZEN element kind. Apply both these operations can lead to that problem as in chromium:992914 To solve this issue, we avoid Object.preventExtensions to change backing store to dictionary by introducing new nonextensible elements kind. These new nonextensible elements kind are handled similar to frozen, sealed element kinds. This change not only fixes the problem but also optimize the performance of nonextensible objects. Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b Bug: chromium:992914, v8:6831 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976 Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Reviewed-by: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#63432}
-
- 15 Jul, 2019 1 commit
-
-
Seth Brenith authored
This change is mostly mechanical, but it's worth mentioning a few slightly interesting cases: - A couple of field definitions didn't match the signedness of their corresponding accessors. - The generated accessors for Smi data use Smi values directly, but usually we want C++ accessors to use ints instead. I added a macro that hides the generated Smi accessors and exposes int accessors, but we might consider generating int accessors directly. - The data held in some fields is described in comments next to the accessor definition for those fields. With automatically generated accessors, those comments need a new home. In this change I put them in the Torque object definition, but I'm open to other suggestions. - gen-postmortem-metadata couldn't find updated class definitions after they got split across multiple lines, so I changed its matching logic. (Ideally debug-support.cc should be a Torque compiler output rather than something that involves parsing C++ with regexes, but this makes it correctly report subclass relationships for now.) - The end offsets generated by Torque were off by one from the values that would be generated by DEFINE_FIELD_OFFSET_CONSTANTS. Change-Id: I3df4fcd27997b46c41ca879065b9d97f6c939f07 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692192Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Reviewed-by: Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#62719}
-
- 09 Jul, 2019 1 commit
-
-
Igor Sheludko authored
Tbr: verwaest@chromium.org Bug: v8:9353 Change-Id: I8164e2235ca43e203410277b86e6f166010c11d6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1687673Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62597}
-
- 28 Jun, 2019 1 commit
-
-
Igor Sheludko authored
The latter is better because it takes field type into account when decompressing field value. Drive-by: use [DECL_]ACCESSOR macros for some fields. Bug: v8:9353 Change-Id: I3d7f07d11b1e379e3e6cf0310d836af6b48c1338 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680539 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Clemens Hammacher <clemensh@chromium.org> Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#62444}
-
- 26 Jun, 2019 2 commits
-
-
Igor Sheludko authored
Bug: v8:9353 Change-Id: I740b2987da1719af6c3d4a6471e7f047801cfd5b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678368Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62391}
-
Igor Sheludko authored
... for defining isolate-full getters. Bug: v8:9353 Change-Id: I91aa11bfe41ab61b2fa72c21018fc38753a846bd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676286Reviewed-by: Ulan Degenbaev <ulan@chromium.org> Reviewed-by: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62375}
-
- 24 Jun, 2019 1 commit
-
-
Mathias Bynens authored
We currently use the class name “JSValue” for JSObjects that wrap primitive values. This name is a common source of confusion. This patch switches to a name that’s more clear. In addition to manual tweaks, the patch applies the following mechanical global replacements: before | after --------------------------------|-------------------------------------- if_valueisnotvalue | if_valueisnotwrapper if_valueisvalue | if_valueiswrapper js_value | js_primitive_wrapper JS_VALUE_TYPE | JS_PRIMITIVE_WRAPPER_TYPE JSPrimitiveWrapperType | JSPrimitiveWrapper type jsvalue | js_primitive_wrapper JSValue | JSPrimitiveWrapper _GENERATED_JSVALUE_FIELDS | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by: Tamer Tas <tmrts@chromium.org> Reviewed-by: Michael Stanton <mvstanton@chromium.org> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Mathias Bynens <mathias@chromium.org> Cr-Commit-Position: refs/heads/master@{#62337}
-
- 18 Jun, 2019 1 commit
-
-
Seth Brenith authored
For every @noVerifier in base.tq, this change either removes it or ensures that it has some annotation explaining why it can't be removed. The @noVerifier usages that can't be removed fall into the following categories: 1. Classes that don't have their own instance types and therefore have no meaningful way to do an Is...() check 2. Fields that might not exist 3. Fields that are waiting for MaybeObject support in Torque Bug: v8:9311 Change-Id: Id452d4151ec07347ae96a9b5f3b26e2ac8065d31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1659134Reviewed-by: Daniel Clifford <danno@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#62263}
-
- 17 Jun, 2019 1 commit
-
-
Seth Brenith authored
This change removes the special case in the Torque compiler for types that descend from JSObject: they will no longer get implicit "| Undefined" appended to their types for verification purposes. It removes any additional custom verification steps in objects-debug that are made redundant by that change. In order to do so safely, I categorized all cases where we were implicitly adding "| Undefined" to the field type, as follows: 1. Classes that aren't using the generated verifier function (we should probably revisit these, but for now we at least know they're safe): - JSGlobalObject - JSFinalizationGroup - JSFinalizationGroupCleanupIterator 2. Classes where the existing verifier is already at least as strict as what we would get after removing the implicit "| Undefined": - JSDate - JSPromise - JSRegExp - JSRegExpStringIterator - WasmMemoryObject - JSWeakRef - JSStringIterator - WasmExceptionObject - JSListFormat (fixed in part 1) - JSPluralRules (fixed in part 1) - JSRelativeTimeFormat (fixed in part 1) - JSSegmenter (fixed in part 1) - JSArrayBufferView (fixed in part 1) - JSTypedArray (fixed in part 1) 3. Classes where, to the best of my knowledge based on code inspection, we already initialize the object correctly to pass the new stricter generated verifier: - JSFunction - JSArrayIterator - JSMessageObject - JSBoundFunction - JSAsyncFromSyncIterator - WasmModuleObject - JSAsyncFunctionObject 4. Classes that needed some adjustment to their initialization order to avoid exposing uninitialized state to the GC: - JSArray (only in Factory::NewJSArray; Runtime_NewArray and CodeStubAssembler::AllocateJSArray already behave fine) - WasmTableObject - JSDateTimeFormat - JSNumberFormat - JSCollator - JSV8BreakIterator - JSLocale - JSSegmentIterator - JSModuleNamespace 5. Classes that had incorrect type definitions in Torque: - WasmGlobalObject (category 4 after correction) 6. Classes that weren't fully initialized due to bugs: - JSGeneratorObject - JSAsyncGeneratorObject Bug: v8:9311 Change-Id: I99ab303d3352423f50a3d0abb6eb0c9b463e7552 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1654980 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org> Reviewed-by: Jakob Gruber <jgruber@chromium.org> Reviewed-by: Sigurd Schneider <sigurds@chromium.org> Cr-Commit-Position: refs/heads/master@{#62228}
-
- 11 Jun, 2019 3 commits
-
-
Igor Sheludko authored
Bug: v8:9353 Change-Id: If184e02eef8cda459a3aa02ef8bee5c337177d30 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648264Reviewed-by: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#62088}
-
Igor Sheludko authored
Bug: v8:9353 Change-Id: Iefeaa8820d3fcccafd92af1ea5e95001fc8ab951 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648262 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62084}
-
Igor Sheludko authored
Tbr: ulan@chromium.org Bug: v8:9353 Change-Id: I99533e21fd186f6d0191f4f500d1a3055a0f92c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648260 Commit-Queue: Igor Sheludko <ishell@chromium.org> Reviewed-by: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#62082}
-