- 10 Jun, 2022 1 commit
-
-
jameslahm authored
... /interpreter. This CL moves cctest/interpreter/{bytecode-expectations-printer, test-bytecode-generator, test-interpreter-intrinsics, interpreter-tester, test-interpreter, test-source-positions, source-position-matcher} to unittests/interpreter/{ bytecode-expectations-printer, bytecode-generator-unittest, interpreter-intrinsics-unittest, interpreter-tester, interpreter-unittest, source-positions-unittest, source-position-matcher}. Bug: v8:12781 Change-Id: I187583bd34f709dd0d7dfc0f92e18f191da0e30f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3609752Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81057}
-
- 09 Jun, 2022 1 commit
-
-
Yolanda Chen authored
Some temp register slots are only used in a short range at the begining of a statement or expression. They can be released earlier to save a slot for later use. After the change, we can see frame size reduced in the switch, class literal and ForOf tests. Bug: v8:12940 Change-Id: I17b412d89353206fc01248cb3eefd2c678bc4ebb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3688565Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Yolanda Chen <yolanda.chen@intel.com> Cr-Commit-Position: refs/heads/main@{#81021}
-
- 22 Apr, 2022 1 commit
-
-
jameslahm authored
This CL extends GetIterator to check whether the result of calling @@iterator is JSReceiver and throw SymbolIteratorInvalid if it's not JSReceiver. GetIterator bytecode involves 3 steps now: - method = GetMethod(obj, @@iterator) - iterator = Call(method, obj) - if(!IsJSReceiver(iterator)) throw SymbolIteratorInvalid [Added] New Builtin: CallIteratorWithFeedbackLazyDeoptContinuation, which is used when lazy deopt is triggered by call @@iterator. Related spec: https://tc39.es/ecma262/#sec-getiterator. Related doc: https://docs.google.com/document/d/1s67HC2f-4zxA_s1Bmm7dfwMFv_KDUfMiWIKkNSeQNKw/edit#heading=h.kdzv8mq4g4ks. Bug: v8:9489 Change-Id: I17952c0f3e24e1e600ee1348809fb188c2c70f8e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563447Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#80112}
-
- 20 Apr, 2022 1 commit
-
-
Jakob Gruber authored
.. which points back at the corresponding feedback vector slot for each JumpLoop bytecode. Bug: v8:12161 Change-Id: I95f4d013544a69e088314655af7eb1dc504a8657 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596166Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80048}
-
- 08 Mar, 2022 1 commit
-
-
Joyee Cheung authored
For background and reasoning, see https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit This is the first step towards pulling the DefineNamedOwn operation out of StoreIC. Summary of the renamed identifiers: Bytecodes: - StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for normal named property sets like obj.x = 1. - StaNamedOwnProperty -> DefineNamedOwnProperty: calls DefineNamedOwnIC (previously StoreOwnIC), and emitted for initialization of named properties in object literals and named public class fields. - StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted for keyed property sets like obj[x] = 1. - StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for initialization of private class fields and computed public class fields. - StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls DefineKeyedOwnPropertyInLiteral runtime function (previously DefineDataPropertyInLiteral) and emitted for initialization of keyed properties in object literals and static class initializers. (note that previously the StoreDataPropertyInLiteral runtime function name was taken by object spreads and array literal creation instead) - LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty -> GetNamedProperty, LdaNamedPropertyFromSuper -> GetNamedPropertyFromSuper: we drop the Sta prefix for the property store operations since the accumulator use is implicit and to make the wording more natural, for symmetry the Lda prefix for the property load operations is also dropped. opcodes: - (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for named properties, compiled from SetNamedProperty (previously StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty - (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define semantics for initializing named own properties in object literal and public class fields, compiled from DefineNamedOwnProperty (previously StaNamedOwnProperty) and lowers to DefineNamedOwnIC (previously StoreOwnIC) - (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics for keyed properties, only compiled from SetKeyedProperty(previously StaKeyedProperty) and lowers to KeyedStoreIC - (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define semantics for initialization of private class fields and computed public class fields, compiled from DefineKeyedOwnProperty (previously StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously KeyedDefineOwnIC). - (JS)StoreDataPropertyInLiteral -> (JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for initialization of keyed properties in object literals and static class initializers, compiled from DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral) and calls the DefineKeyedOwnPropertyInLiteral runtime function (previously DefineDataPropertyInLiteral). Runtime: - DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: following the bytecode/opcodes change, this is used by DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral) for object and class literal initialization. - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple: it's just a simplified version of DefineDataPropertyInLiteral that does not update feedback or perform function name configuration. This is used by object spread and array literal creation. Since we are renaming DefineDataPropertyInLiteral to DefineKeyedOwnPropertyInLiteral, rename this simplified version with a `_Simple` suffix. We can consider merging it into DefineKeyedOwnPropertyInLiteral in the future. See https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU - Other changes following the bytecode/IR changes IC: - StoreOwn -> DefineNamedOwn: used for initialization of named properties in object literals and named public class fields. - StoreOwnIC -> DefineNamedOwnIC - StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn - StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn - IsStoreOwn() -> IsDefineNamedOwn() - DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and keyed defines so we don't need an extra generic predicate. - StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn - StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn - IsDefineOwn() -> IsDefineKeyedOwn() - IsDefineOwnIC() -> IsDefineKeyedOwnIC() - Removing IsKeyedDefineOwnIC() as its now a duplicate of IsDefineKeyedOwnIC() - KeyedDefineOwnIC -> DefineKeyedOwnIC, KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator: make the ordering of terms more consistent - IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is removed since it's just a duplicate of this. - IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the "keyed" part came from, but it's only used when DefineNamedOwnIC (previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly Interpreter & compiler: - BytecodeArrayBuilder: following bytecode changes - StoreNamedProperty -> SetNamedProperty - StoreNamedOwnProperty -> DefineNamedOwnProperty - StoreKeyedProperty -> SetKeyedProperty - DefineKeyedProperty -> DefineKeyedOwnProperty - StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral - FeedbackSlotKind: - kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more consistent - kStoreOwnNamed -> kDefineNamedOwn: following the IC change - kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only used in StoreIC for set semantics - kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used in KeyedStoreIC for set semantics - kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral: following the IC change - BytecodeGraphBuilder - StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the difference between SetNamedProperty and DefineNamedOwnProperty operations. Not changed: - StoreIC and KeyedStoreIC currently contain mixed logic for both Set and Define operations, and the paths are controlled by feedback. The plan is to refactor the hierarchy like this: ``` - StoreIC - DefineNamedOwnIC - SetNamedIC (there could also be a NamedStoreIC if that's helpful) - KeyedStoreIC - SetKeyedIC - DefineKeyedOwnIC - DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC) - StoreInArrayLiteralIC - ... ``` StoreIC and KeyedStoreIC would then contain helpers shared by their subclasses, therefore it still makes sense to keep the word "Store" in their names since they would be generic base classes for both set and define operations. - The Lda and Sta prefixes of bytecodes not involving object properties (e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on property operations, and distinction between Set and Define might be less relevant or nonexistent for bytecodes not involving object properties. We could consider rename some of them in future patches if that's helpful though. Bug: v8:12548 Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79409}
-
- 13 Jan, 2022 1 commit
-
-
Benedikt Meurer authored
This unifies and simplifies the way we instrument async functions for the purpose of async stack traces and async stepping. It does so while retaining the observable behavior on the inspector level (for now). Previously we'd mark the implicit promise of the async function object with the async task ID, and whenever we awaited, we'd copy the async task ID to the throwaway promise that is created by the `await`. This however made things unnecessarily interesting in the following regards: 1. We'd see `DebugDidHandle` and `DebugWillHandle` events after the `AsyncFunctionFinished` events, coming from the throwaway promises, while the implicit promise is "done". This is especially confusing with rejection propagation and requires very complex stepping logic for async functions (after this CL it'll be possible to unify and simplify the stepping logic). 2. We have to thread through the "can suspend" information from the Parser all the way through AsyncFunctionReject/AsyncFunctionResolve to the async function instrumentation to decide whether to cancel the pending task when the async function finishes. This CL changes the instrumentation to only happen (non recurringly) for the throwaway promises allocated upon `await`. This solves both problems mentioned above, and works because upon the first `await` the stack captured for the throwaway promise will include the synchronous part as expected, while upon later `await`s the synchronous part will be empty and the asynchronous part will be the stack captured for the previous throwaway promise (and the V8Debugger automatically short circuits stacks with empty synchronous part). Bug: chromium:1280519, chromium:1277451, chromium:1246867 Change-Id: Id604dabc19ea133ea2e9dd63181b1fc33ccb5eda Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3383775Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78599}
-
- 30 Apr, 2021 1 commit
-
-
Benedikt Meurer authored
Previously we'd attach source positions to implicit returns that are generated when leaving an async function with a promise rejection. This was due to the use of `kNoSourcePosition` on the `end_position` in the `ReturnStatement` nodes as indicator to pick the return position from the function literal, instead of really not putting a source position on that specific `Return` bytecode. This CL adds a dedicated marker to `ReturnStatement` to express that the `BytecodeGenerator` should put the return position from the function literal there instead of overloading the meaning of `kNoSourcePosition`. Bug: chromium:901819, chromium:782461 Fixed: chromium:1199919, chromium:1201706 Change-Id: I3647e0c3d711e9c3d6ae44606b70ec92ad82e1cf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2859945 Auto-Submit: Benedikt Meurer <bmeurer@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#74301}
-
- 02 Mar, 2021 1 commit
-
-
Benedikt Meurer authored
Be explicit about source positions for `Return`s in the BytecodeGenerator, and only do self-healing explicitly in the `ReturnStatement` translation, where an end position of `kNoSourcePosition` is turned into the return position of the function literal. This allows us to reason more easily about which `Return`s actually receive a meaningful source position, and in particular it allows us to construct the internal `Return`s for `yield` and `yield*` with no source position attached to them. Previously they'd get the source position for the implicit (final) return attached to it, which confused the debugger and led to breakpoints being set in the completely wrong spot. Considering the simplified example ``` function* foo(){ var a = 1; } ``` this would previously generate the following bytecode ``` 0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 } 4 : Mov <closure>, r2 7 : Mov <this>, r3 13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3 14 : Star0 13 E> 15 : SuspendGenerator r0, r0-r1, [0] 20 : ResumeGenerator r0, r0-r1 24 : Star2 25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0 29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 } 33 : Ldar r2 13 E> 35 : Throw 36 : Ldar r2 30 S> 38 : Return <=========================== internal Return 27 S> 39 : LdaSmi [1] 41 : Star1 42 : LdaUndefined 30 S> 43 : Return ``` where everything between offset 4 and 42 corresponds to the implicit yield at the beginning of every generator function, in particular the code between 20 and 42 corresponds to that initial yields resumption logic. Notice how the internal Return at offset 38 gets assigned the source position of the function literal (the same as the implicit return at the end). This confuses the debugger quite a bit when trying to set a breakpoint on the closing brace, since it's going in bytecode order and will thus discover the `Return` at offset 38 first (matching the source position 30 it's currently looking for) and setting the breakpoint there. This `Return` bytecode however is only executed when the generator is resumed via `GeneratorPrototype.return()`, and it'll not hit when the developer uses the generator normally, which is not the desired behavior and extremely confusing (especially since stepping on the other hand works as expected). With this patch, we no longer slap a source position (and in particular not the function literal's return position) onto these internal `Return`s as you can see from the generated bytecode below: ``` 0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 } 4 : Mov <closure>, r2 7 : Mov <this>, r3 13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3 14 : Star0 13 E> 15 : SuspendGenerator r0, r0-r1, [0] 20 : ResumeGenerator r0, r0-r1 24 : Star2 25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0 29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 } 33 : Ldar r2 13 E> 35 : Throw 36 : Ldar r2 38 : Return 27 S> 39 : LdaSmi [1] 41 : Star1 42 : LdaUndefined 30 S> 43 : Return ``` This also allows us to remove the break position finding hack that was kept in BreakIterator::BreakIndexFromPosition() for generators and modules. Fixed: chromium:901819 Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#73119}
-
- 17 Feb, 2021 1 commit
-
-
Seth Brenith authored
This is a reland of cf93071c Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Mythri Alle <mythria@chromium.org> Cr-Commit-Position: refs/heads/master@{#72821}
-
- 16 Feb, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit cf93071c. Reason for revert: Speculative revert because of Mac4 GC stress failure: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/16697/overview Original change's description: > [interpreter] Short Star bytecode > > Design doc: > https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit > > This change adds 16 new interpreter opcodes, kStar0 through kStar15, so > that we can use a single byte to represent the common operation of > storing to a low-numbered register. This generally reduces the quantity > of bytecode generated on web sites by 8-9%. > > In order to not degrade speed, a couple of other changes are required: > > The existing lookahead logic to check for Star after certain other > bytecode handlers is updated to check for these new short Star codes > instead. Furthermore, that lookahead logic is updated to contain its own > copy of the dispatch jump rather than merging control flow with the > lookahead-failed case, to improve branch prediction. > > A bunch of constants use bytecode size in bytes as a proxy for the size > or complexity of a function, and are adjusted downward proportionally to > the decrease in generated bytecode size. > > Other small drive-by fix: update generate-bytecode-expectations to emit > \n instead of \r\n on Windows. > > Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180 > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/master@{#72773} TBR=rmcilroy@chromium.org,mythria@chromium.org,seth.brenith@microsoft.com Change-Id: I0162b9400861b90bacef27cca9aebc8ab9d74c10 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2697350Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72777}
-
Seth Brenith authored
Design doc: https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit This change adds 16 new interpreter opcodes, kStar0 through kStar15, so that we can use a single byte to represent the common operation of storing to a low-numbered register. This generally reduces the quantity of bytecode generated on web sites by 8-9%. In order to not degrade speed, a couple of other changes are required: The existing lookahead logic to check for Star after certain other bytecode handlers is updated to check for these new short Star codes instead. Furthermore, that lookahead logic is updated to contain its own copy of the dispatch jump rather than merging control flow with the lookahead-failed case, to improve branch prediction. A bunch of constants use bytecode size in bytes as a proxy for the size or complexity of a function, and are adjusted downward proportionally to the decrease in generated bytecode size. Other small drive-by fix: update generate-bytecode-expectations to emit \n instead of \r\n on Windows. Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72773}
-
- 07 May, 2020 1 commit
-
-
Shu-yu Guo authored
Normative change in ecma262 [1]. Errors thrown by GetMethod(iterator, "return") are suppressed in favor of the original exception. [1] https://github.com/tc39/ecma262/pull/1408 Bug: v8:10397 Change-Id: I0dea8bd677c557cced7103c846416bd81f06f482 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2183400 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#67662}
-
- 24 Apr, 2020 1 commit
-
-
Shu-yu Guo authored
Normative spec change: https://github.com/tc39/ecma262/pull/1814 Bug: v8:10382 Change-Id: Ib17ece9f0c8f75702c828b5336e75cab5d173e5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163876 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#67376}
-
- 20 Mar, 2020 1 commit
-
-
Santiago Aboy Solanes authored
Since now the IterationBody StackChecks are implicit within JumpLoops, we are able to eagerly deopt in them. If we do that, whenever we advance to the next bytecode we don't have to advance to the next literal bytecode, but instead "advance" in the sense of doing the JumpLoop. Adding tests that test this advancing for wide and extra wide JumpLoops. Also, marking JumpLoop as needing source positions since now it has the ability of causing an interrupt. Bug: v8:10149, v8:9960 Fixes: v8:10149 Change-Id: Ib0d9efdfb379e0dfbba7a7f67cba9262668813b0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2064226Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66809}
-
- 11 Mar, 2020 1 commit
-
-
Santiago Aboy Solanes authored
This CL is a step towards making StackChecks implicit. In a follow-up CL said StackChecks will become implicit within JumpLoops. Cq-Include-Trybots: luci.chromium.try:linux-rel Bug: v8:10149, v8:9960 Change-Id: I5ae247be3f7a58ccdf86398cace30724715767a8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2062391 Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#66668}
-
- 10 Feb, 2020 1 commit
-
-
Santiago Aboy Solanes authored
FunctionEntry StackChecks is one of the two cases where we generate a StackCheck bytecode. In these cases, we do stack check against the js limit (not to be confused with the real js limit). Their purpose is to be able to interrupt the running code. We can omit the FunctionEntry StackCheck by embedding its code into the InterpreterEntryTrampoline builtin. We save one bytecode per interpreted function. This change has rippling effects for optimized code, as well as the deoptimizer. Bug: v8:10149, v8:9977, v8:9960 Change-Id: I6156de48b3bc0b519dd21190a8e6214fbe96c78d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914218Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org> Cr-Commit-Position: refs/heads/master@{#66206}
-
- 20 Dec, 2019 1 commit
-
-
Tobias Tebbi authored
This reverts commit 91e3243d. Reason for revert: This deopts to the wrong point. Original change's description: > Extend GetIterator bytecode to perform JSReceiver check on object[Symbol.iterator]() > > Current GetIterator bytecode loads and calls @@iterator property on a > given object. This change extends the bytecode functionality to check > whether the value returned after calling @@iterator property is a valid > JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the > returned value is not a valid JSReceiver. This change absorbs the > functionality of additional two bytecodes - JumpIfJSReceiver and > CallRuntime, that are part of the iterator protocol in the GetIterator > bytecode. > > Bug: v8:9489 > Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Cr-Commit-Position: refs/heads/master@{#63704} TBR=rmcilroy@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9489 Change-Id: I9324b5b01ead29912ad793a1e7b4d009643d7901 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1960288Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#65541}
-
- 05 Dec, 2019 1 commit
-
-
Shu-yu Guo authored
The current error message assumes all classes are named, which results in a double space and awkward wording when calling an anonymous class constructor. Bug: v8:10025 Change-Id: Ibe913152c0816cbbaaa0c7a88db4e415762ae9bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1947336 Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#65354}
-
- 11 Nov, 2019 1 commit
-
-
Jakob Gruber authored
The function-entry stack check should dominate all other instructions in a function. Prior to this CL it was possible to create paths not including a stack check due to SwitchOnGeneratorState: the generator-creation branch had a stack check, while generator-resume branches did not. 0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 } 4 : 27 fe fa Mov <closure>, r1 7 : 27 02 f9 Mov <this>, r2 10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2 14 : 26 fb Star r0 16 : a7 StackCheck 17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0] 22 : b1 fb fb 01 ResumeGenerator r0, r0-r0 [... no stack check here ...] This CL moves the stack check to the beginning of the bytecode array, i.e. before SwitchOnGeneratorState. Bug: chromium:1020031 Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64888}
-
- 24 Oct, 2019 1 commit
-
-
Shu-yu Guo authored
Currently if the argument to matchAll has a null or undefined .flags property, the error message will read "String.prototype.matchAll called on null or undefined", which is very confusing. Drive-by fix: Remove the related and unused MethodInvokedOnNullOrUndefined error. Bug: v8:9895 Change-Id: I3644545282ac8d2156c7a51086e37a0ab7f97a78 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874619 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#64530}
-
- 22 Oct, 2019 3 commits
-
-
Victor Gomes authored
Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695 Commit-Queue: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64477}
-
Clemens Backes authored
This reverts commit 392a1217. Reason for revert: Several failures on mac64 gc stress: https://ci.chromium.org/p/v8/builders/ci/V8%20Mac64%20GC%20Stress/9747 Original change's description: > Reland "Reland "[runtime] Remove extension slots from context objects"" > > This is a reland of c48096d4 > > Original change's description: > > Reland "[runtime] Remove extension slots from context objects" > > > > This is a reland of c07c02e1 > > > > Original change's description: > > > [runtime] Remove extension slots from context objects > > > > > > Context objects have an extension slot, which contains further > > > additional data that depends on the type of the context. > > > > > > This CL removes the extension slot from contexts that don't need > > > them, hence reducing memory. > > > > > > The following contexts will still have an extension slot: native, > > > module, await, block and with contexts. See objects/contexts.h for > > > what the slot is used for. > > > The following contexts will not have an extension slot anymore (they > > > were not used before): script, catch and builtin contexts. > > > Eval and function contexts only have the extension slot if they > > > contain a sloppy eval. > > > > > > Bug: v8:9744 > > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > > Cr-Commit-Position: refs/heads/master@{#64372} > > > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > > > Bug: v8:9744 > > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64380} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64451} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I99a71180c6a00a87478867a8210ff9ceb46cb3ee No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872405Reviewed-by:
Clemens Backes <clemensb@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/master@{#64453}
-
Victor Gomes authored
This is a reland of c48096d4 Original change's description: > Reland "[runtime] Remove extension slots from context objects" > > This is a reland of c07c02e1 > > Original change's description: > > [runtime] Remove extension slots from context objects > > > > Context objects have an extension slot, which contains further > > additional data that depends on the type of the context. > > > > This CL removes the extension slot from contexts that don't need > > them, hence reducing memory. > > > > The following contexts will still have an extension slot: native, > > module, await, block and with contexts. See objects/contexts.h for > > what the slot is used for. > > The following contexts will not have an extension slot anymore (they > > were not used before): script, catch and builtin contexts. > > Eval and function contexts only have the extension slot if they > > contain a sloppy eval. > > > > Bug: v8:9744 > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64372} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64380} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Victor Gomes <victorgomes@google.com> Cr-Commit-Position: refs/heads/master@{#64451}
-
- 21 Oct, 2019 1 commit
-
-
Leszek Swirski authored
This reverts commit c48096d4. Reason for revert: Flaky bot failures (https://bugs.chromium.org/p/v8/issues/detail?id=9744#c9) Original change's description: > Reland "[runtime] Remove extension slots from context objects" > > This is a reland of c07c02e1 > > Original change's description: > > [runtime] Remove extension slots from context objects > > > > Context objects have an extension slot, which contains further > > additional data that depends on the type of the context. > > > > This CL removes the extension slot from contexts that don't need > > them, hence reducing memory. > > > > The following contexts will still have an extension slot: native, > > module, await, block and with contexts. See objects/contexts.h for > > what the slot is used for. > > The following contexts will not have an extension slot anymore (they > > were not used before): script, catch and builtin contexts. > > Eval and function contexts only have the extension slot if they > > contain a sloppy eval. > > > > Bug: v8:9744 > > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > > Commit-Queue: Victor Gomes <victorgomes@google.com> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Auto-Submit: Victor Gomes <victorgomes@google.com> > > Cr-Commit-Position: refs/heads/master@{#64372} > > TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org > > Bug: v8:9744 > Change-Id: I0749cc2d8f59940c25841736634a70047116d647 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64380} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9744 Change-Id: Ia58067b41f1eb5880a52b36ead754d7190ff7f6f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871922Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#64424}
-
- 18 Oct, 2019 3 commits
-
-
Victor Gomes authored
This is a reland of c07c02e1 Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org Bug: v8:9744 Change-Id: I0749cc2d8f59940c25841736634a70047116d647 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Peter Marshall <petermarshall@chromium.org> Auto-Submit: Victor Gomes <victorgomes@google.com> Cr-Commit-Position: refs/heads/master@{#64380}
-
Sathya Gunasekaran authored
This reverts commit c07c02e1. Reason for revert: MSAN failures: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/29251 Original change's description: > [runtime] Remove extension slots from context objects > > Context objects have an extension slot, which contains further > additional data that depends on the type of the context. > > This CL removes the extension slot from contexts that don't need > them, hence reducing memory. > > The following contexts will still have an extension slot: native, > module, await, block and with contexts. See objects/contexts.h for > what the slot is used for. > The following contexts will not have an extension slot anymore (they > were not used before): script, catch and builtin contexts. > Eval and function contexts only have the extension slot if they > contain a sloppy eval. > > Bug: v8:9744 > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 > Commit-Queue: Victor Gomes <victorgomes@google.com> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Auto-Submit: Victor Gomes <victorgomes@google.com> > Cr-Commit-Position: refs/heads/master@{#64372} TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com Change-Id: I98dee04ab4d3ae977053982ec884b738d2f6f623 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9744 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868611Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64373}
-
Victor Gomes authored
Context objects have an extension slot, which contains further additional data that depends on the type of the context. This CL removes the extension slot from contexts that don't need them, hence reducing memory. The following contexts will still have an extension slot: native, module, await, block and with contexts. See objects/contexts.h for what the slot is used for. The following contexts will not have an extension slot anymore (they were not used before): script, catch and builtin contexts. Eval and function contexts only have the extension slot if they contain a sloppy eval. Bug: v8:9744 Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191 Commit-Queue: Victor Gomes <victorgomes@google.com> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Auto-Submit: Victor Gomes <victorgomes@google.com> Cr-Commit-Position: refs/heads/master@{#64372}
-
- 17 Oct, 2019 1 commit
-
-
Toon Verwaest authored
This is a reland of c7c47c68. This makes TSAN happy in addition to: Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Cr-Commit-Position: refs/heads/master@{#64360}
-
- 16 Oct, 2019 3 commits
-
-
Joshua Litt authored
This cl modifies RegExp.prototype.matchAll to throw on non-global regexps. Relevant pull request: https://github.com/tc39/ecma262/pull/1716 Bug: v8:9800 Change-Id: Ie963c1c00441f1c4e2b975c3bab77cca902c7ebc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1846067Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Joshua Litt <joshualitt@chromium.org> Cr-Commit-Position: refs/heads/master@{#64318}
-
Sathya Gunasekaran authored
This reverts commit c7c47c68. Reason for revert: breaks TSAN https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738 Original change's description: > Reland "[runtime] Move Context::native_context to the map" > > This is a reland of f05bae1e > > Previously I presumed that the context read from a frame in the profiler was > a valid context. Turns out that on non-intel we're not guaranteed that the > frame is properly set up. In the case we looked at, the profiler took a > sample right before writing the frame marker indicating a builtin frame, > causing the "context" pointer from that frame to be a bytecode array. Since > we'll read random garbage on the stack as a possible context pointer, I made > the code reading the native context from it a little more defensive. > > Bug: v8:9860 > > Original change's description: > > [runtime] Move Context::native_context to the map > > > > Remove the native context slot from contexts by making context maps > > native-context-specific. Now we require 2 loads to go from a context to the > > native context, but we have 1 field fewer to store when creating contexts. > > > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > > Reviewed-by: Igor Sheludko <ishell@chromium.org> > > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > > Reviewed-by: Maya Lekova <mslekova@chromium.org> > > Reviewed-by: Georg Neis <neis@chromium.org> > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Cr-Commit-Position: refs/heads/master@{#64296} > > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Auto-Submit: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64314} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9860 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64316}
-
Toon Verwaest authored
This is a reland of f05bae1e Previously I presumed that the context read from a frame in the profiler was a valid context. Turns out that on non-intel we're not guaranteed that the frame is properly set up. In the case we looked at, the profiler took a sample right before writing the frame marker indicating a builtin frame, causing the "context" pointer from that frame to be a bytecode array. Since we'll read random garbage on the stack as a possible context pointer, I made the code reading the native context from it a little more defensive. Bug: v8:9860 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Auto-Submit: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64314}
-
- 15 Oct, 2019 2 commits
-
-
Sathya Gunasekaran authored
This reverts commit f05bae1e. Reason for revert: broke arm sim debug https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/17714 https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8899519852984476944/+/steps/Check_-_trusted/0/logs/FunctionDetailsInlining/0 Original change's description: > [runtime] Move Context::native_context to the map > > Remove the native context slot from contexts by making context maps > native-context-specific. Now we require 2 loads to go from a context to the > native context, but we have 1 field fewer to store when creating contexts. > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Reviewed-by: Peter Marshall <petermarshall@chromium.org> > Reviewed-by: Maya Lekova <mslekova@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#64296} TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com Change-Id: Ie7b4086c3a9ab2627ecac599da36b20cf8d1f948 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863200Reviewed-by:
Sathya Gunasekaran <gsathya@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#64299}
-
Toon Verwaest authored
Remove the native context slot from contexts by making context maps native-context-specific. Now we require 2 loads to go from a context to the native context, but we have 1 field fewer to store when creating contexts. Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629 Commit-Queue: Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/master@{#64296}
-
- 12 Sep, 2019 1 commit
-
-
Swapnil Gaikwad authored
Current GetIterator bytecode loads and calls @@iterator property on a given object. This change extends the bytecode functionality to check whether the value returned after calling @@iterator property is a valid JSReceiver. The bytecode throws SymbolIteratorInvalid exception if the returned value is not a valid JSReceiver. This change absorbs the functionality of additional two bytecodes - JumpIfJSReceiver and CallRuntime, that are part of the iterator protocol in the GetIterator bytecode. Bug: v8:9489 Change-Id: I9e84cfe85eeb9a1b8a97ca0595375ac26ba1bbfd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792905Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63704}
-
- 06 Sep, 2019 1 commit
-
-
Swapnil Gaikwad authored
This is a reland of 8b89a7c3 Reland after disabling the test getting deadlocked with '--gc_stress' flag. The CL was reverted because of the 'wasm/grow-shared-memory' test from the mjsunit test suite deadlocked for the 'gc_stress' variant. This is the known issue (v8:9221) and the deadlocking test is now disabled ( https://chromium.googlesource.com/v8/v8.git/+/1c8981e3f4729b7a8220a8823e0a0d45f2a4b788). Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} Bug: v8:9489,v8:9221 Change-Id: I4286255aef457bfdbbe5eb50fc6dabdf9c0955b1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1787427Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Cr-Commit-Position: refs/heads/master@{#63599}
-
- 03 Sep, 2019 2 commits
-
-
Francis McCabe authored
This reverts commit 8b89a7c3. Reason for revert: GC Stress tests timing out. See https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/24272 Original change's description: > Update GetIterator bytecode to load and call object[Symbol.iterator] > > The functionality of the GetIterator bytecode introduced previously is > now extended from loading the @@iterator property to calling the property > as well. This change basically absorbs the functionality of additional > two bytecodes - Star, CallProperty0 in the GetIterator bytecode. > Importantly, this change handles the cases of eager and lazy deoptimization > in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and > eager deopt of the CallProperty0 bytecode, using the continuation builtins. > This mechanism can work as a template for the future bytecode that require > handling such inter-bytecode deopt scenario. The tests evaluating the eager > and lazy deopt scenarios are also included. > > Bug: v8:9489 > Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 > Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Georg Neis <neis@chromium.org> > Reviewed-by: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#63528} TBR=rmcilroy@chromium.org,neis@chromium.org,leszeks@chromium.org,tebbi@chromium.org,swapnilgaikwad@google.com Change-Id: I9ae475f71275f71f1b9e60b8bf0578e21ce2704b No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9489 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783736Reviewed-by:
Francis McCabe <fgm@chromium.org> Commit-Queue: Francis McCabe <fgm@chromium.org> Cr-Commit-Position: refs/heads/master@{#63536}
-
Swapnil Gaikwad authored
The functionality of the GetIterator bytecode introduced previously is now extended from loading the @@iterator property to calling the property as well. This change basically absorbs the functionality of additional two bytecodes - Star, CallProperty0 in the GetIterator bytecode. Importantly, this change handles the cases of eager and lazy deoptimization in the middle of the bytecode, i.e., lazy deopt for LdaNamedProperty and eager deopt of the CallProperty0 bytecode, using the continuation builtins. This mechanism can work as a template for the future bytecode that require handling such inter-bytecode deopt scenario. The tests evaluating the eager and lazy deopt scenarios are also included. Bug: v8:9489 Change-Id: I93eb022bbc3d37582407820aa8482a343cac6c12 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1758313 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#63528}
-
- 26 Aug, 2019 1 commit
-
-
Leszek Swirski authored
Wrap the obj and method registers in BuildGetIterator in a register allocation scope, so that they don't get materialised before the JumpIfJSReceiver jump if they don't have to. Bug: v8:9649 Change-Id: I8dfdd06a23c396124c495b5cb83c078080f1a7c9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1768583 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#63393}
-
- 09 Aug, 2019 1 commit
-
-
Swapnil Gaikwad authored
This is the first in a series of changes to reduce the number of bytecodes generated for the iteration protocol based operations. The GetIterator bytecode introduced in this change currently loads the @@iterator symbol from an object that was previously done using the LdaNamedProperty bytecode. This change uses builtin-based mechanism that would be extended to perform additional operations in the future on absorbing the bytecodes associated with the GetIterator operation from the iteration protocol. Bug: v8:9489 Change-Id: I83b8b55c27bae8260bf227f355eeca1ba80cd8f0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1701852 Commit-Queue: Swapnil Gaikwad <swapnilgaikwad@google.com> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63139}
-
- 08 Aug, 2019 1 commit
-
-
Gus Caplan authored
Cleans up a plethora of JumpIfUndefined().JumpIfNull() occurances by introducing a new JumpIfUndefinedOrNull bytecode. Change-Id: I715e9dd82ca8309e0f3eb6514ddec19b4efe7dbe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743148 Commit-Queue: Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Cr-Commit-Position: refs/heads/master@{#63130}
-