- 26 Apr, 2022 4 commits
-
-
Jakob Kummerow authored
When passing anyref-typed things to Wasm, we cannot expect that all functions are WasmExternalFunctions. Instead of adding a relatively expensive type check to such calls, this patch disables function unwrapping for anyref-typed values. Fixed: v8:12789 Change-Id: Ied57187bac7fde0326634f7b4fc428ad21dc9c2f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605231 Auto-Submit: Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#80179}
-
Victor Gomes authored
- For simplicity we call a builtin when allocating a number. - Elision of boxing/unboxing nodes will be done in a followup CL. Bug: v8:7700 Change-Id: Iec4422d84c6597d3369ab512a1662adb0f077c98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3602514Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#80178}
-
Andreas Haas authored
Table.set has two arguments, the table index and the value. Therefore Table.set was defined with a length of 2. However, the value argument is optional, so the length should actually be 1. Change-Id: Ica2ea13a8e78c974cb011df2b5dc99f8e7eb4bcd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3398496Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#80176}
-
Jakob Gruber authored
This is a reland of commit 91da3883 Fixed: Use an X register for JumpIfCodeTIsMarkedForDeoptimization on arm64. Original change's description: > [osr] Use the new OSR cache > > This CL switches over our OSR system to be based on the feedback > vector osr caches. > > - OSRing to Sparkplug is fully separated from OSR urgency. If > SP code exists, we simply jump to it, no need to maintain an > installation request. > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > If a valid target code object exists, we enter it *without* > calling into runtime to fetch the code object. > - Finally, OSR urgency still remains as the heuristic for > requesting Turbofan OSR compile jobs. Note it no longer has a > double purpose of being a generic untargeted installation > request. > > With the new system in place, we can remove now-unnecessary > hacks: > > - Early OSR tierup is replaced by the standard OSR system. Any > present OSR code is automatically entered. > - The synchronous OSR compilation fallback is removed. With > precise installation (= per-JumpLoop-bytecode) we no longer > have the problem of 'getting unlucky' with JumpLoop/cache entry > mismatches. Execution has moved on while compiling? Simply spawn > a new concurrent compile job. > - Remove the synchronous (non-OSR) Turbofan compile request now > that we always enter available OSR code as early as possible. > - Tiering into Sparkplug no longer messes with OSR state. > > Bug: v8:12161 > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80147} Bug: v8:12161 Change-Id: Ib3597cf1d99cdb5d0f2c5ac18e311914f376231d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606232 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80167}
-
- 25 Apr, 2022 7 commits
-
-
Shu-yu Guo authored
Currently the Isolate is gotten off of the object that the operation is being performed on. Shared objects return the shared Isolate, which is incorrect as it shouldn't be used to run JS, nor does it have HandleScopes open. Plumb the executing Isolate through. Bug: v8:12547 Change-Id: I3d960751c798ac657a6122598154e36d9d504c31 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3606489Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#80163}
-
Nico Hartmann authored
This reverts commit 91da3883. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20arm64%20-%20sim%20-%20pointer%20compression%20-%20builder/21150/overview Original change's description: > [osr] Use the new OSR cache > > This CL switches over our OSR system to be based on the feedback > vector osr caches. > > - OSRing to Sparkplug is fully separated from OSR urgency. If > SP code exists, we simply jump to it, no need to maintain an > installation request. > - Each JumpLoop checks its dedicated FeedbackVector cache slot. > If a valid target code object exists, we enter it *without* > calling into runtime to fetch the code object. > - Finally, OSR urgency still remains as the heuristic for > requesting Turbofan OSR compile jobs. Note it no longer has a > double purpose of being a generic untargeted installation > request. > > With the new system in place, we can remove now-unnecessary > hacks: > > - Early OSR tierup is replaced by the standard OSR system. Any > present OSR code is automatically entered. > - The synchronous OSR compilation fallback is removed. With > precise installation (= per-JumpLoop-bytecode) we no longer > have the problem of 'getting unlucky' with JumpLoop/cache entry > mismatches. Execution has moved on while compiling? Simply spawn > a new concurrent compile job. > - Remove the synchronous (non-OSR) Turbofan compile request now > that we always enter available OSR code as early as possible. > - Tiering into Sparkplug no longer messes with OSR state. > > Bug: v8:12161 > Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Auto-Submit: Jakob Linke <jgruber@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/main@{#80147} Bug: v8:12161 Change-Id: I4a6955f4f20b6f3b13e98d5600c7c6a5205915bc No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3605608 Auto-Submit: Nico Hartmann <nicohartmann@chromium.org> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80148}
-
Jakob Gruber authored
This CL switches over our OSR system to be based on the feedback vector osr caches. - OSRing to Sparkplug is fully separated from OSR urgency. If SP code exists, we simply jump to it, no need to maintain an installation request. - Each JumpLoop checks its dedicated FeedbackVector cache slot. If a valid target code object exists, we enter it *without* calling into runtime to fetch the code object. - Finally, OSR urgency still remains as the heuristic for requesting Turbofan OSR compile jobs. Note it no longer has a double purpose of being a generic untargeted installation request. With the new system in place, we can remove now-unnecessary hacks: - Early OSR tierup is replaced by the standard OSR system. Any present OSR code is automatically entered. - The synchronous OSR compilation fallback is removed. With precise installation (= per-JumpLoop-bytecode) we no longer have the problem of 'getting unlucky' with JumpLoop/cache entry mismatches. Execution has moved on while compiling? Simply spawn a new concurrent compile job. - Remove the synchronous (non-OSR) Turbofan compile request now that we always enter available OSR code as early as possible. - Tiering into Sparkplug no longer messes with OSR state. Bug: v8:12161 Change-Id: I0a85e53d363504b7dac174dbaf69c03c35e66700 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596167 Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#80147}
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: Ifb3776bce308d869064120d5e28a2ea7df943757 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578652Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#80142}
-
jameslahm authored
This is a reland of commit 62632c08. Reason for previous revert: Performance regressions crbug.com/1315724. The reland only optimizes strict equal boolean literal like "a===true" or "a===false", and we generate TestReferenceEqual rather than TestStrictEqual for the comparasion. And also add typed optimization for ReferenceEqual when all inputs are boolean with boolean constant. Original change's description: > [interpreter] Optimize strict equal boolean > > For strict equal boolean literal like "a===true" > or "a===false", we could generate TestReferenceEqual > rather than TestStrictEqual. And in `execution_result()->IsTest()` > case, we could directly emit JumpIfTrue/JumpIfFalse. > > E.g. > ``` > a === true > ``` > Generated Bytecode From: > ``` > LdaGlobal > Star1 > LdaTrue > TestEqualStrict > ``` > To: > ``` > LdaGlobal > Star1 > LdaTrue > TestReferenceEqual > ``` > > E.g. > ``` > if (a === true) > ``` > Generated Bytecode From: > ``` > LdaGlobal > Star1 > LdaTrue > TestEqualStrict > JumpIfFalse > ``` > To > ``` > LdaGlobal > JumpIfTrue > Jump > ``` > > > Bug: v8:6403 > Change-Id: Ieaca147acd2d523ac0d2466e7861afb2d29a1310 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568923 > Reviewed-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@{#79935} Bug: v8:6403 Change-Id: I2ae3ab57dce85313af200fa522e3632af5c3a554 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592039Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80141}
-
Tobias Tebbi authored
TurboShaft is a new, CFG-based IR for TurboFan. This CL adds the basic IR and bidirectional translation from/to TurboFan's sea-of-nodes-based IR for some common operators (still incomplete even for JS). Bug: v8:12783 Change-Id: I162fdf10d583a9275a9f655f5b44b888faf813f6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563562Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#80136}
-
jameslahm authored
- In DeserializeContext, scope info local values snapshot is in order of `name,value,name,value`, and we should ReadValue after ReadString. - Support non-inlined ScopeInfo locals, use NameToIndexHashTable to serialize and deserialize scope info local values when its local count is more than kScopeInfoMaxInlinedLocalNamesSize. Bug: v8:11525, v8:12820 Change-Id: I6ea2c498b594bed7ba8ca5be6af2ab9f0d39aa2b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3600531Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#80130}
-
- 22 Apr, 2022 3 commits
-
-
Frank Tang authored
Spec Text: https://tc39.es/proposal-temporal/#sec-temporal.calendar.prototype.fields Bug: v8:11544 Change-Id: I8df987ddbbf08372da637d7c4620c428fce97cae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3534619Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/main@{#80127}
-
legendecas authored
As per https://tc39.es/ecma262/#sec-hostimportmoduledynamically defined, referencingScriptOrModule in HostImportModuleDynamically can be a Script Record, a Module Record, or null. So to https://tc39.es/proposal-shadowrealm/#sec-shadowrealmimportvalue, the HostImportModuleDynamicallyCallback is been invoked with a `null` resource_name. This may not be considered a breaking change as the parameter resource_name is defined as Local<Value>. Updates d8's DoHostImportModuleDynamically to handle null resource_name, and resolve the dynamically imported specifier relative to the executing script's origin. In this way, we have to set ModuleEmbedderData.origin even if the JavaScript source to be evaluated is Script. Also, a ModuleEmbedderData is created for each ShadowRealm to separate their module maps from the initiator context's. Bug: v8:11989 Change-Id: If70fb140657da4f2dd92eedfcc4515211602aa46 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3522883Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chengzhong Wu <legendecas@gmail.com> Cr-Commit-Position: refs/heads/main@{#80118}
-
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}
-
- 21 Apr, 2022 3 commits
-
-
Tobias Tebbi authored
Bug: v8:12822 Change-Id: Idc8225640e132d175d2c06b530d77fcda7362b55 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599486 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#80092}
-
Leszek Swirski authored
In the simplest way possible. Bug: v8:7700 Change-Id: I155aaf85192b75c89617820d6f127a2ae04c7d9b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3599484 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#80089}
-
Leszek Swirski authored
Add a --maglev-inlining flag, and add some half-baked support for inlining functions when there is call feedback. When the flag is enabled and there is call feedback, we create a nested MaglevGraphBuilder for the current graph, and pause building the graph of the outer function. We manually set up its prologue to set up its frame with the arguments pass into the call, build the body with the nested graph builder. This inner builder knows that it is building an inlined function, and all Return bytecodes will instead emit a Jump to a single merge block at the end of the function, where execution of the outer function can resume. These inner function basic blocks are wired into the outer graph with new JumpToInline and JumpFromInline control nodes. The idea is that subsequent passes will know what the inline function is, and will use these to manage the function stack (particularly for codegen and especially deopts). Bug: v8:7700 Change-Id: I4e9b153f8cf4d06c56e7be6365e7a18b86a773c0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585958 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#80077}
-
- 20 Apr, 2022 3 commits
-
-
legendecas authored
As ecma262 normative change https://github.com/tc39/ecma262/pull/2683, exception thrown on PromiseResolve the broken promises need to be caught and use it to reject the promise returned by `AsyncGenerator.prototype.return`. AsyncGeneratorReturn didn't handle the exception thrown by Await. This CL add an exception handler around it and pass through the caught exception to the returned promise and resume the generator by AsyncGeneratorAwaitResume if the generator is not closed, otherwise reject the promise by AsyncGeneratorReject and drain the queue. Bug: v8:12770 Change-Id: Ic3cac4ce36a6d8ecfeb5d7d762a37a2e0524831c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581158Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Chengzhong Wu <legendecas@gmail.com> Cr-Commit-Position: refs/heads/main@{#80066}
-
Marja Hölttä authored
This enables downloading web snapshots with XMLHttpRequest and deserializing them. Bug: v8:11525 Change-Id: I498f1e99795d474a1715fce9aa1d8c1a34651c42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3585961Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#80064}
-
Clemens Backes authored
The fix is merged to all channels, add the regression test. R=thibaudm@chromium.org Bug: chromium:1314184 Change-Id: I7b7ca13ff34b19c3dbb727d248619dc1ff874873 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3596161Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80044}
-
- 12 Apr, 2022 1 commit
-
-
jameslahm authored
... in Runtime::kCopyDataPropertiesWithExcludedPropertiesOnStack. Bug: v8:11614 Change-Id: Ief6d62fff242d3d38c4e586c7252935d3527ddf1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3581534Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#79937}
-
- 11 Apr, 2022 1 commit
-
-
Clemens Backes authored
The roundss / vroundss instruction is only available on AVX or SSE4_1 hardware. Thus bring back the old code path with much longer code for such old hardware. R=tebbi@chromium.org Bug: chromium:1314363 Change-Id: I79a58627c8b406817330e9f9601234cea28182c1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3578642Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79914}
-
- 09 Apr, 2022 1 commit
-
-
jameslahm authored
This CL changes frame message from `Function.${staticMethodName}` to `${className}.${staticMethodName}` for stack trace in class static methods. Bug: v8:12778 Change-Id: Ie2b9471066a6ba38265412f4af471789bd375c98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3575759Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#79898}
-
- 07 Apr, 2022 2 commits
-
-
Clemens Backes authored
Some test variants and fuzzers set their own GC interval, so the flag specified in the regression test causes flag contradictions. The test failure was flaky anyway, so this change is only a slight reduction in reproducability, and the test will still be used as seed for the fuzzers. R=machenbach@chromium.org Bug: chromium:1313475 Change-Id: I7c7084ab34fe46d691b841921d42a487cc8a1cad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3576114Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79845}
-
Marja Hölttä authored
Bug: v8:11111 Change-Id: I722702faa062e6083496d55cd96ee33d3952998b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571809Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#79840}
-
- 06 Apr, 2022 7 commits
-
-
Shu-yu Guo authored
Bug: v8:12744 Change-Id: I3e356c16554e8bc19afc06b18f4afd7fed2f228e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563540 Commit-Queue: Shu-yu Guo <syg@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#79833}
-
Clemens Backes authored
A worker might be terminated while creating a new Realm. While this was handled mostly correctly already, a DCHECK was places slightly too early, which is fixed by this CL. Also, we avoid printing an error message if we fail to install an extension due to isolate termination. As this is externally triggered, it's not really an error condition. R=jkummerow@chromium.org Bug: chromium:1313475 Change-Id: I67b7fd27002d9b9a33439378d8336fefb2a2371a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571811Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79825}
-
yangwenming authored
With this CL, spilled parameters with ref type in a call to wasm function, will be placed at a consecutive area in the generic JSToWasmWrapper frame as WasmCallDescriptor expected. Bug: v8:12722 Change-Id: I8b82f35b712a32b87abf5100ec46ee499a8178bc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563445Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#79805}
-
Jakob Gruber authored
This flag was a leftover from very early Turbofan days and serves no purpose. Non-OSR TF code automatically uses function context specialization (FCS) when appropriate without looking at the flag value. OSR TF code should never use FCS since it is cached by the SharedFunctionInfo (not by the JSFunction). Bug: v8:12161 Change-Id: Ifb5a10918dbdf34a7164f7e665a230698b793e9e Fixed: chromium:1313419 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3571895 Auto-Submit: Jakob Linke <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79802}
-
Frank Tang authored
Add AO: DefaultMergeFields Spec Text: https://tc39.es/proposal-temporal/#sec-temporal.calendar.prototype.mergefields https://tc39.es/proposal-temporal/#sec-temporal-defaultmergefields Bug: v8:11544 Change-Id: I270f8bffb79e57ef50736ae7ce87cfa53f9cafb1 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3388428Reviewed-by:
Adam Klein <adamk@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/main@{#79795}
-
Shu-yu Guo authored
Bug: v8:12750, v8:11111 Change-Id: I3e9947ec8e2883364178b497a49299a3a96332e4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3569879Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#79792}
-
Shu-yu Guo authored
For the normative change, see https://github.com/tc39/ecma262/pull/2723 Bug: v8:12750, v8:11111 Change-Id: I8e8a2e9b443622b20bb5a4c2d453f782dfbd2ed6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570865 Commit-Queue: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/main@{#79789}
-
- 05 Apr, 2022 4 commits
-
-
Shu-yu Guo authored
The FastArray path for Array#groupBy and Array#groupByToMap does not recheck the input array's length each iteration. This is incorrect since the grouping callback can truncate the length, and we should deopt to the generic path when this happens. Bug: chromium:1312838, v8:12499 Change-Id: Id3a4973e9960500a2f29ed63281ea721777d4dd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570342Reviewed-by:
Marja Hölttä <marja@chromium.org> Auto-Submit: Shu-yu Guo <syg@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#79787}
-
Dominik Inführ authored
HeapAllocator didn't fall back to old space allocation when the heap had no map space. Bug: v8:12578, chromium:1313119 Change-Id: Ic02334f42f9fb80a8a9dcf99a94a7ac16da24053 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3570423Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#79776}
-
Victor Gomes authored
If we have a smi operation in the feedback vector, we emit SmiTag Int32AddWithOverflow and SmiUntag nodes, instead of a generic operation binary node. Change-Id: Idb9ce2b60289fbe492bf269793660b32de23e2b3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3560641Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#79775}
-
Clemens Backes authored
This includes two fixes: 1. For dynamic tiering, the budget must always be reduced when jumping backwards, otherwise we might never trigger tier up, which makes the loop non-interruptible (because the tier-up check replaces the stack check). 2. The d8 worker implementation also needs to terminate the isolate via an interrupt, in addition to scheduling a task, because the worker might never return to the event queue. This CL also fixes one of the failure modes of the inspector fuzzer (see https://crbug.com/1180018). R=jkummerow@chromium.org, marja@chromium.org Bug: v8:12767, chromium:1180018 Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel_ng Change-Id: Ia01d1725fc14931d2ea54c4769c4ee93f866ed63 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3568470Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#79773}
-
- 04 Apr, 2022 4 commits
-
-
Benedikt Meurer authored
This changes the logic for generating method names in `error.stack` to prepend an inferred type name only when the function name is a valid ECMAScript identifiers and does not equal the inferred type name, to (1) give developers more control over the exact name shown in `error.stack`, as well as (2) avoid confusion in the presence of renaming of local variables. Previously we'd leave the function name as-is if it was prefixed by the inferred type name, but that condition is unnecessarily strict, and led to a bunch of inconsistencies around special names like `<instance_member_initializer>` where this dynamic approached often prefixed it with the correct type name, but also sometimes got it wrong and prepended `Object.`, which is very unfortunate and misleading. Specifically for these special names, we'll add logic later in the parser to infer a useful (complete) name. The design doc (https://bit.ly/devtools-method-names-in-stack-traces) contains more background and examples of why we do this change. Doc: https://bit.ly/devtools-method-names-in-stack-traces Fixed: chromium:1294619 Bug: chromium:1283435 Change-Id: Ib8b528ba25255dcd07e9d11044c562c11d699bcb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565724Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#79748}
-
Jakob Gruber authored
This is a reland of commit 3ce690ee Changed for the reland: - Remove the currently-unused BytecodeArray member to avoid MSAN failures. - s/return/continue/ in optimizing-compile-dispatcher. Original change's description: > [osr] Basic support for concurrent OSR > > This CL adds basic support behind --concurrent-osr, > disabled by default. > > When enabled: > 1) the first OSR request starts a concurrent OSR compile job. > 2) on completion, the code object is inserted into the OSR cache. > 3) the next OSR request picks up the cached code (assuming the request > came from the same JumpLoop bytecode). > > We add a new osr optimization marker on the feedback vector to > track whether an OSR compile is currently in progress. > > One fundamental issue remains: step 3) above is not guaranteed to > hit the same JumpLoop, and a mismatch means the OSR'd code cannot > be installed. This will be addressed in a followup by targeting > specific bytecode offsets for the install request. > > This change is based on fanchen.kong@intel.com's earlier > change crrev.com/c/3369361, thank you! > > Bug: v8:12161 > Change-Id: Ib162906dd4b6ba056f62870aea2990f1369df235 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3548820 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Jakob Linke <jgruber@chromium.org> > Cr-Commit-Position: refs/heads/main@{#79685} Bug: v8:12161 Change-Id: I48b100e5980c909ec5e79d190aaea730c83e9386 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3565720Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Auto-Submit: Jakob Linke <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79746}
-
Nikolaos Papaspyrou authored
This CL removes two obsolete regression tests that were taking too long on debug engine builds. Bug: v8:12753 Bug: v8:12754 Change-Id: I818101725caa22fb4b2ed22381f01a2dd9436fe4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563563Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Cr-Commit-Position: refs/heads/main@{#79727}
-
jameslahm authored
In DisassembleFunction runtime, function may have available optimized code and we could directly set the optimized code for the function like in CompileLazy if it's not compiled, which avoids calling Compiler::Compile and failed in DCHECK(!function->HasAvailableOptimizedCode()). Bug: v8:12762 Change-Id: I00001fc598f3fc96dfe86b2367e8ba88f0085fd3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563448Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79722}
-