- 01 Aug, 2022 1 commit
-
-
Nico Weber authored
clang now complains when a BitField for an enum is too wide. We could suppress this, but it seems kind of useful from an uninformed distance, so I made a few bitfields smaller instead. (For AddressingMode, since its size is target-dependent, I added an explicit underlying type to the enum instead, which suppresses the diag on a per-enum basis.) This is without any understanding of the code I'm touching. Especially the change in v8-internal.h feels a bit risky to me. Bug: chromium:1348574 Change-Id: I73395de593045036b72dadf4e3147b5f7e13c958 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3794708 Commit-Queue: Nico Weber <thakis@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Auto-Submit: Nico Weber <thakis@chromium.org> Cr-Commit-Position: refs/heads/main@{#82109}
-
- 05 Jul, 2022 3 commits
-
-
Manos Koukoutos authored
This is a reland of commit 2d74bfa4 Difference compared to original: Restore one needed include. Original change's description: > Remove some unused includes > > Mostly src/api, src/asmjs. src/ast, src/base, src/wasm. > > Bug: v8:13006 > Change-Id: If4e85afe003fda9f8a681077827c3502e939fe57 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3742702 > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81523} Bug: v8:13006 Change-Id: I88c45059572fa25af4e0999f479ba5c28572db7f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3746077Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#81539}
-
Manos Koukoutos authored
This reverts commit 2d74bfa4. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Mac%20-%20arm64%20-%20debug%20builder/7403/overview Original change's description: > Remove some unused includes > > Mostly src/api, src/asmjs. src/ast, src/base, src/wasm. > > Bug: v8:13006 > Change-Id: If4e85afe003fda9f8a681077827c3502e939fe57 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3742702 > Reviewed-by: Thibaud Michaud <thibaudm@chromium.org> > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/main@{#81523} Bug: v8:13006 Change-Id: I7579dc3805ed4cbcd56488c31450c7941b430b1a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3746076 Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Manos Koukoutos <manoskouk@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Manos Koukoutos <manoskouk@chromium.org> Cr-Commit-Position: refs/heads/main@{#81526}
-
Manos Koukoutos authored
Mostly src/api, src/asmjs. src/ast, src/base, src/wasm. Bug: v8:13006 Change-Id: If4e85afe003fda9f8a681077827c3502e939fe57 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3742702Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Commit-Queue: Manos Koukoutos <manoskouk@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#81523}
-
- 20 Jun, 2022 1 commit
-
-
Nikolaos Papaspyrou authored
Mostly in comments, again, not much to be said... One case of UNREACHABLE with return. Bug: v8:12425 Change-Id: I295db355c4794e4205b9b70ebbf51e019ec14060 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3695265Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Nikolaos Papaspyrou <nikolaos@chromium.org> Cr-Commit-Position: refs/heads/main@{#81240}
-
- 13 May, 2022 1 commit
-
-
Clemens Backes authored
Now that we require C++17 support, we can just use the standard static_assert without message, instead of our STATIC_ASSERT macro. R=leszeks@chromium.org Bug: v8:12425 Change-Id: I1d4e39c310b533bcd3a4af33d027827e6c083afe Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3647353Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Clemens Backes <clemensb@chromium.org> Cr-Commit-Position: refs/heads/main@{#80524}
-
- 25 Apr, 2022 1 commit
-
-
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}
-
- 19 Apr, 2022 1 commit
-
-
Jakob Linke authored
This reverts commit 62632c08. Reason for revert: Performance regressions crbug.com/1315724 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, chromium:1315724 Change-Id: I65c520590093724e838f738c795d229687efb9de Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3592752Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Linke <jgruber@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/heads/main@{#80010}
-
- 15 Apr, 2022 1 commit
-
-
jameslahm authored
... on non-iterable object. In CallPrinter::VisitAssignment, when found_ is true, we could print node->target to show the error node value, avoid printing twice for the assignment. Bug: v8:10854 Change-Id: I5f295f46b5639b715f762935e675598d1d780f98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3586763Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: 王澳 <wangao.james@bytedance.com> Cr-Commit-Position: refs/heads/main@{#79997}
-
- 12 Apr, 2022 1 commit
-
-
jameslahm authored
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/+/3568923Reviewed-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}
-
- 23 Mar, 2022 2 commits
-
-
Joyee Cheung authored
Since assignments to read-only private references can be skipped due to short-circuiting in logical assignments, we should not eagerly emit the error of invalid writes, and should instead load the values as usual, only emitting an error when the assignment happens, which can be handled by BytecodeGenerator::BuildAssignment(). Bug: v8:12680, v8:8330, v8:10372 Change-Id: Ia5fea9090bc48b0af8a9c8d6f95174f7aa2d86f8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3509298Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79583}
-
Shu-yu Guo authored
Change-Id: Ie74e9bb523463a4c9a0f23a1788246b376e08b14 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3543169Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#79576}
-
- 10 Mar, 2022 1 commit
-
-
jameslahm authored
when BuildCreateArrayLiteral In spread calls, create array literal boilerplates for BuildCreateArrayLiteral rather than emit array literals without any boilerplates Bug: v8:11582 Change-Id: Ia0538bd043eab040c3059440e982c7f0037d1a3f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3507126Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79447}
-
- 07 Mar, 2022 1 commit
-
-
jameslahm authored
when has_simple_parameters_ is false in DeclareArguments - According to https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-functiondeclarationinstantiation step 28, arguments var declaration in function should be binding to arguments parameterBindings when has_simple_parameters_ is false. - According to https://tc39.es/ecma262/multipage/ordinary-and-exotic-objects-behaviours.html#sec-funct> step 18, we should set arguments_ is nullptr if "arguments" is an element of lexicalNames only when has_simple_parameters is true. Bug: v8:12671 Change-Id: I542f80e2c8653ae05b65feb0036e4ade2e653a53 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3499251Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#79382}
-
- 03 Mar, 2022 1 commit
-
-
Michael Lippautz authored
The utility type is independent of V8 and useful for cppgc as well. Move to base/ to allow reusing. Change-Id: I9de9b4a87bb113fb4c2232d90253afb0f38faa68 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497336Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#79346}
-
- 21 Feb, 2022 1 commit
-
-
Camillo Bruni authored
- Avoid lookup if there is no template_weakmap yet - More explicit DisallowGarbageCollection scopes - Avoid handles when settings properties - Speed up Object::GetSimpleHash by loading only instance_type once Change-Id: Ib588607340a0c56dc1ba26c3e89485560222a688 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3463717Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#79189}
-
- 16 Feb, 2022 1 commit
-
-
Jakob Gruber authored
- bbudge - delphick - gsathya - mvstanton - sigurds - zhin + tebbi in src/torque/OWNERS Change-Id: I81ff27860cede273f1874b6079fa89e09486a99a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3461937Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#79113}
-
- 10 Feb, 2022 1 commit
-
-
Joyee Cheung authored
Handle the case of nested super() by checking if the class scope contains a private brand. In this case the ContextScope chain is different from the actual context chain so this added back the AddPrivateBrand() runtime function but with the additional step of walking the context chain to get the correct class context that will be stored as the value of the brand property for the debugger. Bug: v8:12354 Change-Id: Ieeb9b9d6372bfbb1a39c4c2dc9e9848e9109f02a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3275137Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#79032}
-
- 07 Feb, 2022 2 commits
-
-
Dominik Inführ authored
Verification code in HeapObject::set_map() is supposed to run on the main thread since object layout change is only supported on the main thread. There are some users of set_map() on background threads though, which resulted in crashes. Since those users all perform a safe map transition, we introduce a separate method for this purpose: HeapObject::set_map_safe_transition(). This method behaves just like set_map() but verifies that this is a safe map transition and not an object layout change and therefore can be used on background threads as well. This CL also adds a DCHECK to HeapObject::set_map() to ensure we run this method only on the main thread. Bug: chromium:1293484 Change-Id: I25de6fda08de21b8b7a3645cf0ea5b1334e8a2f6 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3439905Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#78978}
-
Patrick Thier authored
We introduce a new information type ForwardingIndex to be stored in the Name::Hash field (to be used in the future). To do so we use the 2 least significant bit to distinguish types of information stored in the hash field (in contrast to only bit 1 to distinguis integer indicies from "real" hashes). This motivated a refactor to use base::BitField for the hash field. Bug: v8:12007 Change-Id: I651c86807edfc218792d0db12379374eaa50c930 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3432385Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#78975}
-
- 31 Jan, 2022 1 commit
-
-
Victor Gomes authored
- This enables a hash table for local names in ScopeInfo. - Drive by fix iterating local names in FinalizeReparsedClassScope Bug: v8:12315 Change-Id: I02c22bfdc4f1d91f19f368885fca24b2a577d26e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3422632 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#78876}
-
- 27 Jan, 2022 1 commit
-
-
Victor Gomes authored
- It changes ContextSlotIndex from static to non-static. - Updates ContextSlotIndex and ScriptContextTable::Lookup to use handles, since it is necessary for the NameToIndexHashTable::Add - Adds a NameToIndexHashTableLookup to CSA. - Renames LocalNamesIterator to LocalNamesRange and iterates the hashtable when local names are not inlined. Bug: v8:12315 Change-Id: I2c8c933002fe73f4def145bc207825823262d743 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3406751Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#78818}
-
- 26 Jan, 2022 1 commit
-
-
Joyee Cheung authored
When reparsing the class scope to collect initializers in sloppy mode, the class scope may still have a scope info without any allocated variables. If its outer scope doesn't have an outer scope (which means the outer scope in the optimized scope chain becomes the script scope), we should also set the scope info in the script scope as is done in Scope::DeserializeScopeChain() for the scope resolution. Bug: chromium:1290587, v8:10704 Change-Id: I7804d53f330e59d4ab0405a11b132569f348b55d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3413647Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#78784}
-
- 24 Jan, 2022 1 commit
-
-
Joyee Cheung authored
This is a reland of 91f08378 When the class scope does not need a context, the deserialized outer scope of the initializer scope would not be the class scope, and we should not and do not need to use it to fix up the allocation information of the context-allocated variables. The original patch did not consider this case and resulted in a regression when we tried to reparse the initializer function to look for destructuring assignment errors. This fixes the regression by not deserializing the class scope that's going to be reparsed, and using the positions of the scopes to tell whether the scope info matches the reparsed scope and can be used to fix up the allocation info. Original change's description: > [class] implement reparsing of class instance member initializers > > Previously, since the source code for the synthetic class instance > member initializer function was recorded as the span from the first > initializer to the last initializer, there was no way to reparse the > class and recompile the initializer function. It was working for > most use cases because the code for the initializer function was > generated eagarly and it was usually alive as long as the class was > alive, so the initializer wouldn't normally be lazily parsed. This > didn't work, however, when the class was snapshotted with > v8::SnapshotCreator::FunctionCodeHandling::kClear, > becuase then we needed to recompile the initializer when the class > was instantiated. This patch implements the reparsing so that > these classes can work with FunctionCodeHandling::kClear. > > This patch refactors ParserBase::ParseClassLiteral() so that we can > reuse it for both parsing the class body normally and reparsing it > to collect initializers. When reparsing the synthetic initializer > function, we rewind the scanner to the beginning of the class, and > parse the class body to collect the initializers. During the > reparsing, field initializers are parsed with the full parser while > methods of the class are pre-parsed. > > A few notable changes: > > - Extended the source range of the initializer function to cover the > entire class so that we can rewind the scanner to parse the class > body to collect initializers (previously, it starts from the first > field initializer and ends at the last initializer). This resulted > some expectation changes in the debugger tests, though the > initializers remain debuggable. > - A temporary ClassScope is created during reparsing. After the class > is reparsed, we use the information from the ScopeInfo to update > the allocated indices of the variables in the ClassScope. > > Bug: v8:10704 > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Cr-Commit-Position: refs/heads/main@{#78299} Bug: chromium:1278086, chromium:1278085, v8:10704 Change-Id: Iea4f1f6dc398846cbe322adc16f6fffd6d2dfdf3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325912Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#78745}
-
- 19 Jan, 2022 1 commit
-
-
Shu-yu Guo authored
super.property accesses in heritage positions like `class C extends super.property` should resolve super in the current scope, not C's class scope. Bug: chromium:1282096 Change-Id: I7ef815bc02cfff35a2898ef9f39b133d1114046c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3400150Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#78687}
-
- 17 Jan, 2022 1 commit
-
-
Victor Gomes authored
This is a reland of f605d778 Adds a GC safe (using handles) and unsafe versions of the iterator. V8HeapExplorer needs an unsafe one, since it does not allow the creation of handles. Original change's description: > [runtime] Adds LocalNameIterator > > ScopeInfo will contain either inlined (array) local names or > a hash table (names => index) containing the local names. > > We abstract iteration with LocalNameIterator and remove > ContextLocalName since accessing a local name by index in > the hash table would be expensive. > > This CL only implements the iterator for the array. > > Bug: v8:12315 > Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78623} Bug: v8:12315 Change-Id: I6288a08b9c342cd3a9cabcb621c40bb44c08c9c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3394706Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#78653}
-
- 14 Jan, 2022 3 commits
-
-
Leszek Swirski authored
This reverts commit f605d778. Reason for revert: Segfaults: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/36908/overview Original change's description: > [runtime] Adds LocalNameIterator > > ScopeInfo will contain either inlined (array) local names or > a hash table (names => index) containing the local names. > > We abstract iteration with LocalNameIterator and remove > ContextLocalName since accessing a local name by index in > the hash table would be expensive. > > This CL only implements the iterator for the array. > > Bug: v8:12315 > Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Victor Gomes <victorgomes@chromium.org> > Cr-Commit-Position: refs/heads/main@{#78623} Bug: v8:12315 Change-Id: Ibabe231f4357a3dd02d24b89847d579b83867a1a No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386385 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Owners-Override: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78625}
-
Victor Gomes authored
ScopeInfo will contain either inlined (array) local names or a hash table (names => index) containing the local names. We abstract iteration with LocalNameIterator and remove ContextLocalName since accessing a local name by index in the hash table would be expensive. This CL only implements the iterator for the array. Bug: v8:12315 Change-Id: I2c62802652fca1cf47815ce8768a3f7487f2c39f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386603Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#78623}
-
Victor Gomes authored
ScopeInfo will contain either inlined (array) local names or a hash table (names => index) containing the local names. If we have the local names inlined, we should save the class variable context slot index. If we have a hash table instead, we should save the class variable offset in the internal hash table storage. Bug: v8:12315 Change-Id: Ifd9ae4f285d11fc034e8560c8558038b38a474fb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386599Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#78621}
-
- 13 Jan, 2022 1 commit
-
-
Jochen Eisinger authored
I'm not going to realistically work on resolving them. Change-Id: Idd59fe5758ab7132fa2412477242bc045b0ee02d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3378636Reviewed-by:
Yang Guo <yangguo@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Jochen Eisinger <jochen@chromium.org> Auto-Submit: Jochen Eisinger <jochen@chromium.org> Cr-Commit-Position: refs/heads/main@{#78602}
-
- 13 Dec, 2021 1 commit
-
-
Leszek Swirski authored
This is a reland of 2418d22a Reland fixes: * Rebase this 2+ year old change
* Unpoison the kept segment before zapping it to make ASAN happy. * Carefully adjust allocation size tracking fields to compensate for kept segment. Original change's description: > [zone] Keep one page when we Zone::Reset for reuse > > Change-Id: I50c6124d3da5b35d4156c066f38d10d2dc966567 > Reviewed-on: https://chromium-review.googlesource.com/c/1349246 > Reviewed-by: Igor Sheludko <ishell@chromium.org> > Commit-Queue: Toon Verwaest <verwaest@chromium.org> > Cr-Commit-Position: refs/heads/master@{#57793} Change-Id: Iaffde5b38b3d683af081b1878464dd4c66be5af8 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322833Reviewed-by:Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78348}
-
- 10 Dec, 2021 1 commit
-
-
Leszek Swirski authored
This allows us to reuse AstValueFactory's string table across multiple parsers, while still releasing memory after each individual parse. This is mild overkill for all the single parses that don't reuse AstValueFactories, but there at least the AstRawStrings now end up grouped together in memory, so that might have mild cache benefits. Change-Id: I0b378760b601fa4ec6559a0dca5d7ed6f895e992 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3322764Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78338}
-
- 09 Dec, 2021 1 commit
-
-
Joyee Cheung authored
This reverts commit 91f08378. Reason for revert: It's a fairly big change, and the clusterfuzz found some bugs. Will reland with the fix after M98 branch point. Original change's description: > [class] implement reparsing of class instance member initializers > > Previously, since the source code for the synthetic class instance > member initializer function was recorded as the span from the first > initializer to the last initializer, there was no way to reparse the > class and recompile the initializer function. It was working for > most use cases because the code for the initializer function was > generated eagarly and it was usually alive as long as the class was > alive, so the initializer wouldn't normally be lazily parsed. This > didn't work, however, when the class was snapshotted with > v8::SnapshotCreator::FunctionCodeHandling::kClear, > becuase then we needed to recompile the initializer when the class > was instantiated. This patch implements the reparsing so that > these classes can work with FunctionCodeHandling::kClear. > > This patch refactors ParserBase::ParseClassLiteral() so that we can > reuse it for both parsing the class body normally and reparsing it > to collect initializers. When reparsing the synthetic initializer > function, we rewind the scanner to the beginning of the class, and > parse the class body to collect the initializers. During the > reparsing, field initializers are parsed with the full parser while > methods of the class are pre-parsed. > > A few notable changes: > > - Extended the source range of the initializer function to cover the > entire class so that we can rewind the scanner to parse the class > body to collect initializers (previously, it starts from the first > field initializer and ends at the last initializer). This resulted > some expectation changes in the debugger tests, though the > initializers remain debuggable. > - A temporary ClassScope is created during reparsing. After the class > is reparsed, we use the information from the ScopeInfo to update > the allocated indices of the variables in the ClassScope. > > Bug: v8:10704 > Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Joyee Cheung <joyee@igalia.com> > Cr-Commit-Position: refs/heads/main@{#78299} Bug: v8:10704 Change-Id: I039cb728ebf0ada438a8f26c7d2c2547dbe3bf2d No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3325328 Auto-Submit: Joyee Cheung <joyee@igalia.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78315}
-
- 08 Dec, 2021 2 commits
-
-
Joyee Cheung authored
Previously, since the source code for the synthetic class instance member initializer function was recorded as the span from the first initializer to the last initializer, there was no way to reparse the class and recompile the initializer function. It was working for most use cases because the code for the initializer function was generated eagarly and it was usually alive as long as the class was alive, so the initializer wouldn't normally be lazily parsed. This didn't work, however, when the class was snapshotted with v8::SnapshotCreator::FunctionCodeHandling::kClear, becuase then we needed to recompile the initializer when the class was instantiated. This patch implements the reparsing so that these classes can work with FunctionCodeHandling::kClear. This patch refactors ParserBase::ParseClassLiteral() so that we can reuse it for both parsing the class body normally and reparsing it to collect initializers. When reparsing the synthetic initializer function, we rewind the scanner to the beginning of the class, and parse the class body to collect the initializers. During the reparsing, field initializers are parsed with the full parser while methods of the class are pre-parsed. A few notable changes: - Extended the source range of the initializer function to cover the entire class so that we can rewind the scanner to parse the class body to collect initializers (previously, it starts from the first field initializer and ends at the last initializer). This resulted some expectation changes in the debugger tests, though the initializers remain debuggable. - A temporary ClassScope is created during reparsing. After the class is reparsed, we use the information from the ScopeInfo to update the allocated indices of the variables in the ClassScope. Bug: v8:10704 Change-Id: Ifb6431a1447d8844f2a548283d59158742fe9027 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2988830Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Joyee Cheung <joyee@igalia.com> Cr-Commit-Position: refs/heads/main@{#78299}
-
Leszek Swirski authored
Introduce a ReusableUnoptimizedCompileState class, passed to ParseInfo, which stores a couple of pointers and most importantly the Zone and AstValueFactory of the parse. This allows the Zone and AstValueFactory to be reused across multiple parses, rather than re-initialising per-Parse. With this, we can amend the LazyCompileDispatcher to initialise one LocalIsolate, Zone and AstValueFactory per background thread loop, rather than one per compile task, which allows us to reduce per-task costs and re-use the AstValueFactory's string table and previous String internalizations. Change-Id: Ia0e29c4e31fbe29af57674ebb10916865d38b2ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3313106Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#78289}
-
- 01 Dec, 2021 1 commit
-
-
Leszek Swirski authored
Add suppose for compiling non-eager, non-top-level inner functions in parallel, using the compiler dispatcher. This behaviour can be enabled with --parallel-compile-tasks-for-lazy. There are a couple of consequences: * To support this we need support for off-thread ScopeInfo deserialization, so this adds that too. * The previous --parallel-compile-tasks flag is renamed to the more descriptive --parallel-compile-tasks-for-eager-toplevel. * Both parallel-compile-tasks flags are moved onto UnoptimizedCompileFlags so that they can be enabled/disabled on a per-compile basis (e.g. enabled for streaming, disabled for re-parsing). * asm.js compilations can now happen without an active Context (in the compiler dispatcher's idle finalization) so we can't get a ContextId for metric reporting; we'd need to somehow fix this if we wanted asm.js UKM but for now it's probably fine. * Took the opportunity to clean up some of the "can preparse" logic in the parser. Change-Id: I20b1ec6a6bacfe268808edc8d812b92370c5840d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3281924 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Emanuel Ziegler <ecmziegler@chromium.org> Cr-Commit-Position: refs/heads/main@{#78183}
-
- 16 Nov, 2021 1 commit
-
-
Ng Zhi An authored
Bug: v8:12244,v8:12245 Change-Id: Id74afa611b2b8556ef86c715497b6daddc8ea7a0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3276931Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77928}
-
- 15 Nov, 2021 1 commit
-
-
Leszek Swirski authored
Posting compile tasks from the parser has several issues: 1. We don't know how many functions there will be total, so we can't yet allocate shared_function_infos array on the Script 2. Without this array, inner function compiles can't look up their own inner functions during bytecode finalization, so we can't run that finalization before script parse completes 3. Scope analysis can't have run yet, so we can only post top-level function tasks and if we allocate SharedFunctionInfos early they are forced into a bit of a limbo state without an outer ScopeInfo. Instead, we can post compile tasks during bytecode generation. Then, the script parse is guaranteed to have completed, so we'll have a shared_function_infos array and we will have allocated ScopeInfos already. This also opens the door for posting tasks for compiling more inner functions than just top-level, as well as generating better code for functions/methods that reference same-script top-level let/const/class. Bug: chromium:1267680 Change-Id: Ie1a3a3c6f1b264c4ef28cd4763bfc6dc08f45d4d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3277884 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Cr-Commit-Position: refs/heads/main@{#77894}
-
- 04 Nov, 2021 2 commits
-
-
Leszek Swirski authored
Remove the concept of JobId from LazyCompileDispatcher, and make SFIs the canonical id for these jobs. This has several consequences: * We no longer split enqueing a job and registering a SFI with that job. We did this previously because we could not allocate SFIs in the Parser -- now with LocalHeap we can, so we do. * We remove the separate Job vector, and make the SFI IdentityMap hold pointers to Jobs directly. This requires a small amount of extra care to deallocate Jobs when removing them from the map, but it means not having to allocate new global handles for jobs. * The SFI is passed into the BackgroundCompileTask instead of the script, so our task finalization doesn't need the SFI anymore. * We no longer need to iterate ParallelTasks after compiling (to register SFIs), so we can get rid of ParallelTasks entirely and access the dispatcher directly from the parser. There are a few drive-bys since we're touching this code: * Jobs are move to have a "state" variable rather than a collection of bools, for stricter DCHECKing. * There's no longer a set of "currently running" jobs, since this was only used to check if a job is running, we can instead inspect the job's state directly. * s/LazyCompilerDispatcher/LazyCompileDispatcher/g Change-Id: I85e4bd6db108f5e8e7fe2e919c548ce45796dd50 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259647 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#77712}
-
Leszek Swirski authored
Some post-compile flag setting was unnecessary, since those flags originally came from the SFI they were being set on. Also, DontOptimizeReason was never actually set, so we can remove it entirely. Change-Id: Ic07821fc20ba4e16a2bd8b9e8ac8c1b266aa4067 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260510 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Auto-Submit: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#77702}
-