- 27 Jan, 2022 1 commit
-
-
Igor Sheludko authored
... which was using incorrect cage base value for reading map field. Drive-by: fix CodeDataContainer verifier - the value returned by code().InstructionStart() might not always be equal to cached code entry point value when shared pointer compression cage is enabled. Bug: v8:11880, chromium:1291299 Change-Id: I1338717095a9a1ad2c056f0af0181eabaef88431 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3420308Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78815}
-
- 26 Jan, 2022 1 commit
-
-
Thibaud Michaud authored
Create and return the chained promise, which resumes the suspended wasm continuation once the JS promise resolves: - Add stub for the WasmResume builtin, which will resume the given suspender. - Add the JS function wrapper for the builtin. - On suspension, return promise.then(onFulfilled) to the prompt. R=ahaas@chromium.org CC=fgm@chromium.org Bug: v8:12191 Change-Id: I2d6136b2bd610daa4be1880f347b7bdf897e75ac Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3404776Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Cr-Commit-Position: refs/heads/main@{#78787}
-
- 25 Jan, 2022 1 commit
-
-
legendecas authored
1. Expose all the functions to empty builtins. 2. Wire up the basic structure of ShadowRealm and internal slots. Bug: v8:11989 Change-Id: If7545fe18a74b2bd4b70a1a25776e41f03aaff89 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3195532Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Chengzhong Wu <legendecas@gmail.com> Cr-Commit-Position: refs/heads/main@{#78757}
-
- 17 Jan, 2022 1 commit
-
-
Victor Gomes authored
In preparation to use the hash table in the scope_info, we setup a hashtable from name to indices. Bug: v8:12315 Change-Id: I77f1eb40191c2fb2d40127e1e84dbc41ca2e4b70 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3386804Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#78646}
-
- 10 Jan, 2022 1 commit
-
-
Benedikt Meurer authored
When creating a new JSError object (or using the non-standard API `Error.captureStackTrace`) V8 would previously capture the "simple stack trace" (as FixedArray of CallSiteInfo instances) to be used for the non- standard `error.stack` property, and if the inspector was active also capture the "detailed stack trace" (as FixedArray of StackFrameInfo instances). This turns out to be quite a lot of overhead, both in terms of execution time as well as memory pressure, especially since the information needed for the inspector is a proper subset of the information needed by `error.stack`. So this CL addresses the above issue by capturing only the "simple stack trace" (in the common case) and computing the "detailed stack trace" from the "simple stack trace" when on demand. This is accomplished by introducing a new ErrorStackData container that is used to store the stack trace information on JSErrors when the inspector is active. When capturing stack trace for a JSError object while the inspector is active, we take the maximum of the program controlled stack trace limit and the inspector requested stack trace limit, and memorize the program controlled stack trace limit for later formatting (to ensure that the presence of the inspector is not observable by the program). On the `standalone.js` benchmark from crbug.com/1283162 (with the default max call stack size of 200) we reduce execution time by around 16% compared to ToT. And compared to V8 9.9.4 (the version prior to the regression in crbug.com/1280831), we are 6% faster now. Doc: https://bit.ly/v8-cheaper-inspector-stack-traces Bug: chromium:1280831, chromium:1278650, chromium:1258599 Bug: chromium:1280803, chromium:1280832, chromium:1280818 Fixed: chromium:1283162 Change-Id: I57dac73e0ecf7d50ea57c3eb4981067deb28133e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3366660Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78542}
-
- 15 Dec, 2021 1 commit
-
-
Benedikt Meurer authored
This is the final change list in the list of refactorings to split off the implementations of v8::StackFrame and CallSite objects (as used by the V8 JavaScript stack API). See https://bit.ly/v8-stack-frame for the whole story. This CL adds the v8::internal::StackFrameInfo class as new backing implementation of v8::StackFrame, and puts it into debug-objects.tq to indicate that it's used for the debugger API only. This new class is lightweight and only holds on to static information about the stack frame, and is thus usable for the V8 inspector to implement async stack traces in a cheaper manner going forward. Doc: https://bit.ly/v8-stack-frame Bug: chromium:1258599, chromium:1278650 Fixed: chromium:1278647 Change-Id: I4dbf2d850f47797263af225895129499169aad02 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3302794 Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Cr-Commit-Position: refs/heads/main@{#78382}
-
- 14 Dec, 2021 3 commits
-
-
Igor Sheludko authored
This CL migrates JSFunction's code accessors to CodeT. Bug: v8:11880 Change-Id: I8cf367eb79cc1d59548dd4f3e18c010f76f101cb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3330466Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78365}
-
Benedikt Meurer authored
This is the second step in the refactoring to make v8::StackFrame more lightweight and usable for (long time storage) by the V8 inspector (see https://bit.ly/v8-stack-frame for an overview). This is a purely mechanical change without any functional aspects. The intention is to make the use case for the CallSiteInfo objects clear, namely to serve as the backing store for the CallSite objects exposed via the Error.prepareStackTrace() API and used under the hood to implement the error.stack accessor. Doc: https://bit.ly/v8-stack-frame Bug: chromium:1258599, chromium:1278647, chromium:1278650 Change-Id: I39dffd1f1a8e5158ddc56f2a0a2b1b28321f487a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3300138Reviewed-by:
Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Simon Zünd <szuend@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/main@{#78361}
-
Igor Sheludko authored
Drive-by: fix TSAN issue. Bug: v8:11880 Change-Id: I8a31391c6a1855a20a243eb740e4e3e1223ecbbf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3333930Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78360}
-
- 30 Nov, 2021 1 commit
-
-
Igor Sheludko authored
... by using cage-friendly versions of HeapObject::IsBlah(), HeapObject::map(), HeapObject::map_word() and HeapObject::Size() on hot paths. Bug: v8:11880 Change-Id: I70b72e46cc867b6b2ddbc48cd5e6a74ae4208397 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3308800Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#78161}
-
- 15 Nov, 2021 1 commit
-
-
Ng Zhi An authored
Bug: v8:12244,v8:12245 Change-Id: I3029cfb8e9afdcb5e53aa406359aa7246c23ea40 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3274021Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Jakob Kummerow <jkummerow@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77906}
-
- 04 Nov, 2021 1 commit
-
-
Jakob Gruber authored
- Use a StringShape instead of repeatedly querying type. - Add a shortcut for already-flat strings. - Unhandlify where possible (all except SlowFlatten). - Mark String::Flatten and StringShape methods V8_INLINE. - Add a specialized ConsString::IsFlat overload. Drive-by: Various (add const, remove this->, helper methods). Bug: v8:12195 Change-Id: If20df12bc29c29cff2005fdc9bd826ed9f303463 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259527 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/main@{#77701}
-
- 03 Nov, 2021 3 commits
-
-
Dominik Inführ authored
When a GC happens during context deserialization, NativeContext::retained_maps might be uninitialized and not store a WeakArrayList but Smi 0. Bug: v8:12198 Change-Id: I03c1dfaa013c47907af67bb13b9277d67ca5ffae Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259662Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Dominik Inführ <dinfuehr@chromium.org> Cr-Commit-Position: refs/heads/main@{#77692}
-
Nico Hartmann authored
This reverts commit a3480b55. Reason for revert: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20-%20debug%20-%20header%20includes/22234/overview Original change's description: > Reland "[torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants" > > This is a reland of 7366f6e2 > > The test that failed after the initial commit was just flaky and has > been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341 > > Original change's description: > > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants > > > > Torque currently generates constants like kStartOfWeakFieldsOffset and > > kEndOfStrongFieldsOffset, which can be used when writing custom > > BodyDescriptors. However, these offsets have some potentially confusing > > behaviors: > > > > * They don't take inheritance into account and describe only the fields > > defined by the current class itself, so there might be (for example) > > strong fields before kStartOfStrongFieldsOffset if they were defined > > by a superclass. > > * kStartOfWeakFieldsOffset points to the first field defined in Torque > > using the keyword `weak`, which indicates fields with *custom* > > weakness semantics (those that should be visited with > > IterateCustomWeakPointers), not those that may contain standard weak > > pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd > > like to also rename `weak` to `@customWeak`.) > > > > Given that these constants have very low usage and somewhat bizarre > > semantics, I propose that we remove them. This change does so, and > > updates the existing usages to either define the required constants > > directly in C++ or not use them. I know that defining these constants in > > C++ is more brittle, but I think that brittle and clear is better than > > automatic and incomprehensible. > > > > Bug: v8:7793 > > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731 > > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > > Cr-Commit-Position: refs/heads/main@{#77411} > > Bug: v8:7793 > Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Michael Lippautz <mlippautz@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#77688} Bug: v8:7793 Change-Id: I7b9667268901b7aef85a95832d40860056e61050 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3259656Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Owners-Override: Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77689}
-
Seth Brenith authored
This is a reland of 7366f6e2 The test that failed after the initial commit was just flaky and has been fixed; see https://bugs.chromium.org/p/v8/issues/detail?id=12341 Original change's description: > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants > > Torque currently generates constants like kStartOfWeakFieldsOffset and > kEndOfStrongFieldsOffset, which can be used when writing custom > BodyDescriptors. However, these offsets have some potentially confusing > behaviors: > > * They don't take inheritance into account and describe only the fields > defined by the current class itself, so there might be (for example) > strong fields before kStartOfStrongFieldsOffset if they were defined > by a superclass. > * kStartOfWeakFieldsOffset points to the first field defined in Torque > using the keyword `weak`, which indicates fields with *custom* > weakness semantics (those that should be visited with > IterateCustomWeakPointers), not those that may contain standard weak > pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd > like to also rename `weak` to `@customWeak`.) > > Given that these constants have very low usage and somewhat bizarre > semantics, I propose that we remove them. This change does so, and > updates the existing usages to either define the required constants > directly in C++ or not use them. I know that defining these constants in > C++ is more brittle, but I think that brittle and clear is better than > automatic and incomprehensible. > > Bug: v8:7793 > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#77411} Bug: v8:7793 Change-Id: Iefdd4014ce4b85b48c19ead79a0316774a5ecd45 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3258082Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77688}
-
- 28 Oct, 2021 1 commit
-
-
Tobias Tebbi authored
This is a reland of 45227ffd Differences: - Handle one more flags conflict in variants.py. - Disallow %VerifyType without --concurrent-recompilation. Original change's description: > [turbofan] extend type asserts to cover all JS types > > Extend type assertions to all types covering JavaScript values. > This is achieved by allocating type representations on the heap using > newly defined HeapObject subclasses. To allocate these in the compiler, > we disable concurrent compilation for the --assert-types flag for now. > > Fix two type errors that came up with the existing tests: > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of > OtherObject. > 2. OperationTyper::NumberToString(Type) can type the result as the > HeapConstant Factory::zero_string(). However, NumberToString does > not always produce this string. To avoid regressions, the CL keeps > the HeapConstant type and changes the runtime and builtin code to > always produce the canonical "0" string. > > A few tests were failing because they check for truncations to work > and prevent deoptimization. However, AssertType nodes destroy all > truncations (which is by design), so these tests are incompatible > and now disabled for the assert_types variant. > > Drive-by fix: a few minor Torque issues that came up. > > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77565} Change-Id: I5b3c6745c6ad349ff8c2b199d9afdf0a9b5a7392 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247035 Auto-Submit: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77596}
-
- 27 Oct, 2021 2 commits
-
-
Maya Lekova authored
This reverts commit 45227ffd. Reason for revert: Breaks on gc_stress mode, see https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/35988/overview Original change's description: > [turbofan] extend type asserts to cover all JS types > > Extend type assertions to all types covering JavaScript values. > This is achieved by allocating type representations on the heap using > newly defined HeapObject subclasses. To allocate these in the compiler, > we disable concurrent compilation for the --assert-types flag for now. > > Fix two type errors that came up with the existing tests: > 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of > OtherObject. > 2. OperationTyper::NumberToString(Type) can type the result as the > HeapConstant Factory::zero_string(). However, NumberToString does > not always produce this string. To avoid regressions, the CL keeps > the HeapConstant type and changes the runtime and builtin code to > always produce the canonical "0" string. > > A few tests were failing because they check for truncations to work > and prevent deoptimization. However, AssertType nodes destroy all > truncations (which is by design), so these tests are incompatible > and now disabled for the assert_types variant. > > Drive-by fix: a few minor Torque issues that came up. > > Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Omer Katz <omerkatz@chromium.org> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/main@{#77565} Change-Id: Ia779a11fc811846194c7a8d1e40b372b265e7ea4 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247034 Auto-Submit: Maya Lekova <mslekova@chromium.org> Owners-Override: Maya Lekova <mslekova@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@{#77566}
-
Tobias Tebbi authored
Extend type assertions to all types covering JavaScript values. This is achieved by allocating type representations on the heap using newly defined HeapObject subclasses. To allocate these in the compiler, we disable concurrent compilation for the --assert-types flag for now. Fix two type errors that came up with the existing tests: 1. JSCreateKeyValueArray has type Array (i.e., a JSArray) instead of OtherObject. 2. OperationTyper::NumberToString(Type) can type the result as the HeapConstant Factory::zero_string(). However, NumberToString does not always produce this string. To avoid regressions, the CL keeps the HeapConstant type and changes the runtime and builtin code to always produce the canonical "0" string. A few tests were failing because they check for truncations to work and prevent deoptimization. However, AssertType nodes destroy all truncations (which is by design), so these tests are incompatible and now disabled for the assert_types variant. Drive-by fix: a few minor Torque issues that came up. Change-Id: If03b7851f7e6803a2f69edead4fa91231998f764 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3234717Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/main@{#77565}
-
- 26 Oct, 2021 1 commit
-
-
Thibaud Michaud authored
R=ahaas@chromium.org CC=fgm@chromium.org Bug: v8:12191 Change-Id: Ied9ab5fa5009e5ab268d1c9893729d8210ae62ce Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3220344 Commit-Queue: Thibaud Michaud <thibaudm@chromium.org> Reviewed-by:
Andreas Haas <ahaas@chromium.org> Cr-Commit-Position: refs/heads/main@{#77542}
-
- 19 Oct, 2021 1 commit
-
-
Igor Sheludko authored
... by explicitly passing pointer compression cage base value to various IsXXX() and map() calls in order to avoid using incorrect auto-computed cage base value when applied to objects allocated in external code space. This CL also introduces IsCodeObject(HeapObject) predicate which checks the IS_EXECUTABLE bit in the page header's flags. Bug: v8:11880 Change-Id: Ib44398c3125392e46e939044a9bd27e09d7944d5 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3229368Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/main@{#77459}
-
- 15 Oct, 2021 2 commits
-
-
Leszek Swirski authored
This reverts commit 7366f6e2. Reason for revert: Speculative revert for cctest/test-debug-helper/GetObjectProperties failures https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8833300564873660401/+/u/Check/GetObjectProperties Original change's description: > [torque] Don't generate k(?:Start|End)Of\w+FieldsOffset constants > > Torque currently generates constants like kStartOfWeakFieldsOffset and > kEndOfStrongFieldsOffset, which can be used when writing custom > BodyDescriptors. However, these offsets have some potentially confusing > behaviors: > > * They don't take inheritance into account and describe only the fields > defined by the current class itself, so there might be (for example) > strong fields before kStartOfStrongFieldsOffset if they were defined > by a superclass. > * kStartOfWeakFieldsOffset points to the first field defined in Torque > using the keyword `weak`, which indicates fields with *custom* > weakness semantics (those that should be visited with > IterateCustomWeakPointers), not those that may contain standard weak > pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd > like to also rename `weak` to `@customWeak`.) > > Given that these constants have very low usage and somewhat bizarre > semantics, I propose that we remove them. This change does so, and > updates the existing usages to either define the required constants > directly in C++ or not use them. I know that defining these constants in > C++ is more brittle, but I think that brittle and clear is better than > automatic and incomprehensible. > > Bug: v8:7793 > Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#77411} Bug: v8:7793 Change-Id: Ia12b5d773db35739283ca8871d3dd6922413cc82 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3226783 Auto-Submit: Leszek Swirski <leszeks@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Leszek Swirski <leszeks@chromium.org> Owners-Override: Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/main@{#77415}
-
Seth Brenith authored
Torque currently generates constants like kStartOfWeakFieldsOffset and kEndOfStrongFieldsOffset, which can be used when writing custom BodyDescriptors. However, these offsets have some potentially confusing behaviors: * They don't take inheritance into account and describe only the fields defined by the current class itself, so there might be (for example) strong fields before kStartOfStrongFieldsOffset if they were defined by a superclass. * kStartOfWeakFieldsOffset points to the first field defined in Torque using the keyword `weak`, which indicates fields with *custom* weakness semantics (those that should be visited with IterateCustomWeakPointers), not those that may contain standard weak pointers (visited with IterateMaybeWeakPointers). (As a follow-up, I'd like to also rename `weak` to `@customWeak`.) Given that these constants have very low usage and somewhat bizarre semantics, I propose that we remove them. This change does so, and updates the existing usages to either define the required constants directly in C++ or not use them. I know that defining these constants in C++ is more brittle, but I think that brittle and clear is better than automatic and incomprehensible. Bug: v8:7793 Change-Id: I87f8c85ccae4027f61ac73d4e7e4e2820e92003b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3199731Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77411}
-
- 11 Oct, 2021 2 commits
-
-
Shu-yu Guo authored
When --shared-string-table is passed, in-place-internalizable strings are promoted into the shared old space to maintain the invariant that in-place internalization can be done without copying. Also some drive-by comment fixes and removal of unnecessary 'explicit' on multi-parameter constructors. Bug: v8:12007 Change-Id: I467d865e41934b1d5cdf85cbecc85c4befbfeb21 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193591 Auto-Submit: Shu-yu Guo <syg@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/main@{#77326}
-
Victor Gomes authored
Compiling Sparkplug on the heap saved 10% of the CompileBaseline RCS metric, but that came with too much code complexity. Since in the end that corresponds to < 1% of the entire compilation time, we decided to revert this project. This reverts: commit e29b2ae4 commit d1f2a83b commit 4666e182 commit a1147408 commit e0d4254f commit 9ab8422d commit a3b24ecc commit 1eb87706 commit fe5c9dfd commit 7ac3b55a commit 7e95f30e commit 323b5962 commit 6bf0b704 commit e82b368b commit 5020d83e commit 642a4673 commit ec7b99d5 commit fb4f89ae commit 208854bb commit 63be6dde Bug: v8:12158 Change-Id: I9f2539be6c7d80c6e243c9ab173e3c5bb0dff97d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136453 Auto-Submit: Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Cr-Commit-Position: refs/heads/main@{#77319}
-
- 08 Oct, 2021 1 commit
-
-
Frank Tang authored
This is a reland of 0adc1410 1. Fork out test/mjsunit/temporal/function-exist.js test to test/mjsunit/temporal/function-exist-no-i18n.js and mark function-exist FAIL in no_i18n build. Original change's description: > [Temporal] Part 1 - Skeleton > > 1. Expose all the functions to empty buildins. > 2. Wire up basic structure of classes and internal slots. > > Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/ > > This is just a CL to establish a skeleton for Temporal. > The Temporal is very big. The prototype CL is in > https://chromium-review.googlesource.com/c/v8/v8/+/2967755 > but too big to be reviewed so I break up the basic structure here first. > > Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel > Bug: v8:11544 > Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76819} Bug: v8:11544 Change-Id: I60eaface94ba9b3408cb235cd1ae425151a36732 Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160324Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/main@{#77303}
-
- 07 Oct, 2021 1 commit
-
-
Camillo Bruni authored
- Add Context extension slot verification - Fix ScriptContextTable printing - Make Context::scope_info() inlinable Bug: chromium:1244145 Change-Id: Ide71866885f3f92de6561dfef6911ee52c6094f9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3211578 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/main@{#77286}
-
- 30 Sep, 2021 1 commit
-
-
Seth Brenith authored
This is a reland of 94958172 Original change's description: > [torque] Get rid of @noVerifier annotation > > As one small step toward reducing annotations, I propose that all > classes get generated verifiers unless they've opted out of C++ class > generation via @doNotGenerateCppClass, and that generated verifiers > always verify every Torque-defined field. If a generated verifier is > incorrect, such as for JSFunction or DataHandler, we can just avoid > calling it and hand-code the verification. > > Bug: v8:7793 > Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#77145} Bug: v8:7793 Change-Id: I3da34705bf9fc2b1886161f8f59c7275583f7fc4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194812 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/main@{#77168}
-
- 29 Sep, 2021 4 commits
-
-
Maya Lekova authored
This reverts commit 94958172. Reason for revert: Breaks arm/arm64 ports, e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim/30120/blamelist Original change's description: > [torque] Get rid of @noVerifier annotation > > As one small step toward reducing annotations, I propose that all > classes get generated verifiers unless they've opted out of C++ class > generation via @doNotGenerateCppClass, and that generated verifiers > always verify every Torque-defined field. If a generated verifier is > incorrect, such as for JSFunction or DataHandler, we can just avoid > calling it and hand-code the verification. > > Bug: v8:7793 > Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#77145} Bug: v8:7793 Change-Id: I56da8a9726d23470e927be1be5e7bcede1399861 No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3194262 Auto-Submit: Maya Lekova <mslekova@chromium.org> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Owners-Override: Maya Lekova <mslekova@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77146}
-
Seth Brenith authored
As one small step toward reducing annotations, I propose that all classes get generated verifiers unless they've opted out of C++ class generation via @doNotGenerateCppClass, and that generated verifiers always verify every Torque-defined field. If a generated verifier is incorrect, such as for JSFunction or DataHandler, we can just avoid calling it and hand-code the verification. Bug: v8:7793 Change-Id: I7c0edb660574d0c688a59c7e90c41ee7ad464b42 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171758Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#77145}
-
Patrick Thier authored
Class Constructors are special, because they are callable but [[Call]] raises an exception. Instead of checking if a JS function is a class constructor for every JS function call, this CL adds a new instance type for class constructors. This way we can use a fast instance type range check for the common case, and only check for class constructors in the uncommon case were a class constructor is called and when we need to raise an exception. Change-Id: Ic6fdd9829722d05559fdfd01f6100c61873a0872 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3186434Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#77140}
-
Jakob Gruber authored
.. and refactor js-regexp.h. - Hide the generic DataAt/SetDataAt accessors and replace them by dedicated accessors. Use the common lower_case naming scheme for these. - Shuffle around definitions in js-regexp.h s.t. they are in a meaningful order. - Dedupe the source/flags accessors - these fields are stored both on the instance and on the data array. We keep only accessors for the instance. Previously, these were disambiguated through naming oddities (e.g. Pattern() returned data->source). Change-Id: I3d53c8b095f0d59621ff779608438f7fa5e8c92a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3193534 Auto-Submit: Jakob Gruber <jgruber@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Maya Lekova <mslekova@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Patrick Thier <pthier@chromium.org> Cr-Commit-Position: refs/heads/main@{#77138}
-
- 28 Sep, 2021 1 commit
-
-
Ng Zhi An authored
Bug: v8:12244 Change-Id: I7ea68dd74a376221631d7f56b4a012207f68a1ec Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3182899Reviewed-by:
Hannes Payer <hpayer@chromium.org> Commit-Queue: Zhi An Ng <zhin@chromium.org> Cr-Commit-Position: refs/heads/main@{#77129}
-
- 14 Sep, 2021 2 commits
-
-
Deepti Gandluri authored
This reverts commit 0adc1410. Reason for revert: Reverting due to fail on V8 Linux - noi18n - debug https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket/8836095186331011153/+/u/Check_-_default/function-exist Original change's description: > [Temporal] Part 1 - Skeleton > > 1. Expose all the functions to empty buildins. > 2. Wire up basic structure of classes and internal slots. > > Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/ > > This is just a CL to establish a skeleton for Temporal. > The Temporal is very big. The prototype CL is in > https://chromium-review.googlesource.com/c/v8/v8/+/2967755 > but too big to be reviewed so I break up the basic structure here first. > > Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel > Bug: v8:11544 > Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561 > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Shu-yu Guo <syg@chromium.org> > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Frank Tang <ftang@chromium.org> > Cr-Commit-Position: refs/heads/main@{#76819} Bug: v8:11544 Change-Id: I358f671452a986c8e87d1f831ab5eb1550a38441 Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel No-Presubmit: true No-Tree-Checks: true No-Try: true Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3160467 Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Commit-Queue: Deepti Gandluri <gdeepti@chromium.org> Auto-Submit: Deepti Gandluri <gdeepti@chromium.org> Owners-Override: Deepti Gandluri <gdeepti@chromium.org> Cr-Commit-Position: refs/heads/main@{#76821}
-
Frank Tang authored
1. Expose all the functions to empty buildins. 2. Wire up basic structure of classes and internal slots. Design Doc: https://docs.google.com/document/d/1Huu2OUlmveBh4wjgx0D7ouC9O9vSdiZWaRK3OwkQZU0/ This is just a CL to establish a skeleton for Temporal. The Temporal is very big. The prototype CL is in https://chromium-review.googlesource.com/c/v8/v8/+/2967755 but too big to be reviewed so I break up the basic structure here first. Cq-Include-Trybots: luci.v8.try:v8_linux64_bazel Bug: v8:11544 Change-Id: I10d09e3c2530e5b1a6ba60014a2294e138879ff3 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3092561Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Frank Tang <ftang@chromium.org> Cr-Commit-Position: refs/heads/main@{#76819}
-
- 01 Sep, 2021 1 commit
-
-
Hao Xu authored
This is a reland of commit 40af03b8 The original CL failed one test in Windows, and this CL fix this issue. Original changes's description: > [codegen] Align the code start at 64 byte in x64 > > In order to make loop header aligned at 64 byte (relative to memory address), code start should also be aligned at 64 byte. > > Bug: chromium:1231471 > Change-Id: I95390babd9cc78492e0beb0f1b03901eb481d5d5 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094167 > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > Commit-Queue: Hao A Xu <hao.a.xu@intel.com> > Cr-Commit-Position: refs/heads/main@{#76484} Bug: chromium:1231471 Change-Id: Ia927305c792c7486588bc15e9e87840d6db18478 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3133957Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Commit-Queue: Hao A Xu <hao.a.xu@intel.com> Cr-Commit-Position: refs/heads/main@{#76617}
-
- 30 Aug, 2021 1 commit
-
-
Seth Brenith authored
Most Torque-defined extern classes already use CPP class generation. As Nico pointed out in [1], it would be nice to convert the remaining classes and remove this option. This change converts most of those remaining classes. I know that the future of Torque-defined classes is a subject of some debate right now, but I think that it's worth doing a few mechanical changes to reduce the existing variety of options. A couple of minor fixes in the Torque compiler were required so that it generates correct code for shapes. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I7e6087153a18d6ee80e67926793e8ba8e01d501e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3015666Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Anton Bikineev <bikineev@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/main@{#76586}
-
- 09 Aug, 2021 2 commits
-
-
Sathya Gunasekaran authored
Rather than depending on slow signature checks, receiver type checks are performed using fast numeric instance type checks. This CL adds a instance type range for embedders to assign values and uses these to perform type checks. Bug: v8:11476 Change-Id: Ie8236ae47ca0ba93ae76a7e690b81aa0a2b0f3e2 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2883623Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#76162}
-
Camillo Bruni authored
Change-Id: Ia324f486f138757017951c0d2b83502937b950d9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3075362 Auto-Submit: Camillo Bruni <cbruni@chromium.org> Commit-Queue: Omer Katz <omerkatz@chromium.org> Reviewed-by:
Omer Katz <omerkatz@chromium.org> Reviewed-by:
Shu-yu Guo <syg@chromium.org> Cr-Commit-Position: refs/heads/master@{#76158}
-
- 20 Jul, 2021 1 commit
-
-
Seth Brenith authored
Most Torque-defined extern classes already use @generateCppClass. As Nico pointed out in [1], it would be nice to convert the remaining classes and remove this option. This change converts most of those remaining classes. I know that the future of Torque-defined classes is a subject of some debate right now, but I think that it's worth doing a few mechanical changes to reduce the existing variety of options. Changes that don't exactly follow the usual pattern: 1. BigIntBase, MutableBigInt: we can define these without a body, and then Torque treats them as "really external" rather than "kind of external, but with some Torque-generated parts". 2. RegExpMatchInfo: moved its inline functions into a separate file, which the generated -tq.cc file requires. [1] https://docs.google.com/document/d/1q_gZLnXd4bGnCx3IUfbln46K3bSs9UHBGasy9McQtHI/edit# Bug: v8:8952 Change-Id: I84c7958a295caa0bab847683c05022e18c921cad Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027742Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#75817}
-
- 19 Jul, 2021 1 commit
-
-
Igor Sheludko authored
... for visiting slots containing pointers to Code objects when external code space mode is enabled. These slots will require different handling once the code space is moved out of the V8 heap cage. This CL also introduces IsValidCodeObject() predicate similar to IsValidHeapObject() for checking if given HeapObject is a valid Code object. Tbr: cbruni@chromium.org Bug: v8:11880 Change-Id: I430940f4503cebfd2a6d387e44349810991a93e9 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032085Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Michael Lippautz <mlippautz@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#75787}
-