- 10 Feb, 2021 1 commit
-
-
Georg Neis authored
This reverts commit 42cd9eb7. Reason for revert: Clusterfuzz issues, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=1176318 Original change's description: > [compiler] Directly read PropertyCells > > Main changes: > > - Introduce a new broker data kind kBackgroundSerialized for objects > that can be serialized in the background (when direct reads are on). > (I'm planning to remove kPossiblyBackgroundSerialized in a followup, > in favor of a dynamic choice of kSerialized or kBackgroundSerialized). > - Make PropertyCell use that new kind. > - Introduce a bottleneck in runtime code for changes to PropertyCells > and make sure that a certain protocol is followed that allows > concurrent reads from the background thread. > - Improve interface of PropertyCell in various ways. > > Bug: v8:7790 > Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462 > Reviewed-by: Toon Verwaest <verwaest@chromium.org> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Commit-Queue: Georg Neis <neis@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72586} TBR=ulan@chromium.org,neis@chromium.org,verwaest@chromium.org,nicohartmann@chromium.org Change-Id: Id04145760c49fa379bc5a3fc16eba664025a9180 Bug: v8:7790 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2685125Reviewed-by:
Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72619}
-
- 09 Feb, 2021 3 commits
-
-
Georg Neis authored
Main changes: - Introduce a new broker data kind kBackgroundSerialized for objects that can be serialized in the background (when direct reads are on). (I'm planning to remove kPossiblyBackgroundSerialized in a followup, in favor of a dynamic choice of kSerialized or kBackgroundSerialized). - Make PropertyCell use that new kind. - Introduce a bottleneck in runtime code for changes to PropertyCells and make sure that a certain protocol is followed that allows concurrent reads from the background thread. - Improve interface of PropertyCell in various ways. Bug: v8:7790 Change-Id: If3d7926c3b894808811348b4b2bed153f5c06897 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2661462Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#72586}
-
Frank Emrich authored
This CL is part of a series that adds the C++ implementation of SwissNameDictionary, a deterministic property backing store based on Swiss Tables. This CL contains most of the boilerplate code for introducing a new instance type. Bug: v8:11388 Change-Id: Id263b8138a8ce4b465fb28d968223d2e1aaf05a4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2672030Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#72582}
-
Benedikt Meurer authored
BREAKING CHANGE: The values of Wasm locals, stack, and globals are now represented as objects instead of holding the (primitive) values directly, and SIMD128 values are no longer represented as Uint8Arrays. The DWARF extension has been prepared for this breaking change. The new `WasmValue` comes with `type` and `value` properties that hold its contents. The motivation here is that this is a more extensible approach. In case of SIMD128, the `value` property holds the canonical string representation, which has the additional advantage that these values can be compared with `===` (and `==`). This partially reverts https://crrev.com/c/2614428, the main difference here being that WasmValue is now a proper JSObject that can be exposed on the DebugEvaluate proxy API. Screenshot: https://imgur.com/rcahNKM.png Bug: chromium:1170282, chromium:1071432, chromium:1159402 Change-Id: Iea304e3680775123c41deb4c3d172ac949da1b98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2643384Reviewed-by:
Philip Pfaffe <pfaffe@chromium.org> Reviewed-by:
Zhi An Ng <zhin@chromium.org> Reviewed-by:
Yang Guo <yangguo@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#72570}
-
- 29 Jan, 2021 1 commit
-
-
Marja Hölttä authored
Fix 1: Track Scope::needs_home_object and Scope::uses_super_property accurately. When "eval" is seen, figure out whether it can access "super" and if yes, set the corresponding home object as needed. Fix 2: The object literal scope shouldn't be entered for things inside spreads. Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Previous reland: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I9686e0d90cd0c1128757eca440a88748897ee91e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2655509 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72422}
-
- 28 Jan, 2021 1 commit
-
-
Marja Hölttä authored
This reverts commit f6450b97. Reason for revert: ClusterFuzz bugs Original change's description: > Reland [super] Store home object in Context instead of JSFunction > > 1) Computed property keys (esp functions in them) shouldn't be inside > the object literal scope. > > 2) I was using an imprecise "maybe uses super" and storing it to > preparse data. This won't fly, since it pollutes sister scopes and > leads to confusion wrt whether an object literal needs a home object > or not. Made it precise (mostly cancelling changes in the original CL). > > 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for > this_function (which made it used) -> inconsistent scopes between > parsing and preparsing. > > 4) MultipleEntryBlockContextScope was messing up the accumulator > > Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 > > This saves memory (the home object doesn't need to be stored for each > method, but only once per class) and hopefully makes the home object > a constant in the optimized code. > > Detailed documentation of the changes: > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing > > Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 > Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220 > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Commit-Queue: Marja Hölttä <marja@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72169} TBR=marja@chromium.org,leszeks@chromium.org # Not skipping CQ checks because original CL landed > 1 day ago. Bug: v8:9237 Bug: chromium:1167918 Bug: chromium:1167981 Bug: chromium:1167988 Bug: chromium:1168055 Bug: chromium:1171195 Bug: chromium:1171600 Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by:
Marja Hölttä <marja@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72391}
-
- 20 Jan, 2021 1 commit
-
-
Seth Brenith authored
This change adds Torque field definitions for ScopeInfo and begins to use the Torque-generated accessors in some places. It does not change the in-memory layout of ScopeInfo. Torque compiler changes: - Fix an issue where the parser created constexpr types for classes based on the class name rather than the `generates` clause. This meant that generated accessors referred to the imaginary type HashTable rather than the real C++ type FixedArray. - Don't pass Isolate* through the generated runtime functions that implement Torque macros. Maybe we'll need it eventually, but we don't right now and it complicates a lot of things. - Don't emit `kSomeFieldOffset` if some_field has an unknown offset. Instead, emit a member function `SomeFieldOffset()` which fetches the slice for some_field and returns its offset. - Emit an `AllocatedSize()` member function for classes which have complex length expressions. It fetches the slice for the last field and performs the multiply&add to compute the total object size. - Emit field accessors for fields with complex length expressions, using the new offset functions. - Fix a few minor bugs where Torque can write uncompilable code. With this change, most code still treats ScopeInfo like a FixedArray, so I would like to follow up with some additional changes: 1. Generate a GC visitor for ScopeInfo and use it 2. Generate accessors for struct-typed fields (indexed or otherwise), and use them 3. Get rid of the FixedArray-style get and set accessors; use TaggedField::load and similar instead 4. Inherit from HeapObject rather than FixedArrayBase to remove the unnecessary `length` field After that, there will only be one ugly part left: initialization. I think it's possible to generate a factory function that takes a bunch of iterator parameters and returns a fully-formed, verifiably correct ScopeInfo instance, but doing so is more complicated than the four mostly-mechanical changes listed above. Bug: v8:7793 Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#72187}
-
- 19 Jan, 2021 3 commits
-
-
Marja Hölttä authored
1) Computed property keys (esp functions in them) shouldn't be inside the object literal scope. 2) I was using an imprecise "maybe uses super" and storing it to preparse data. This won't fly, since it pollutes sister scopes and leads to confusion wrt whether an object literal needs a home object or not. Made it precise (mostly cancelling changes in the original CL). 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for this_function (which made it used) -> inconsistent scopes between parsing and preparsing. 4) MultipleEntryBlockContextScope was messing up the accumulator Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055 Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#72169}
-
Sathya Gunasekaran authored
This will allow us optimize the protector cell checks in the fast path from checking against the function object in every context to just doing a range check against the instance type. This patch adds new instance types for constructor functions that require such protector cell checks. Bug: v8:11256 Change-Id: Iea722f9c6326dfa470149dd02e689a23942097f4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2595442Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Cr-Commit-Position: refs/heads/master@{#72146}
-
Maya Lekova authored
This reverts commit 4d5b878b. Reason for revert: Suspected to cause a failure on ChromeOS, which is blocking the roll - https://chromium-review.googlesource.com/c/chromium/src/+/2636263 Original change's description: > [super] Store home object in Context instead of JSFunction > > This saves memory (the home object doesn't need to be stored for each > method, but only once per class) and hopefully makes the home object > a constant in the optimized code. > > Detailed documentation of the changes: > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing > > Bug: v8:9237 > Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 > Commit-Queue: Marja Hölttä <marja@chromium.org> > Reviewed-by: Leszek Swirski <leszeks@chromium.org> > Cr-Commit-Position: refs/heads/master@{#72137} TBR=marja@chromium.org,leszeks@chromium.org Change-Id: Idc5a8240cef4da8893ccc608ee4ae0d7206a1ba8 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:9237 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637215Reviewed-by:
Maya Lekova <mslekova@chromium.org> Commit-Queue: Maya Lekova <mslekova@chromium.org> Cr-Commit-Position: refs/heads/master@{#72142}
-
- 18 Jan, 2021 2 commits
-
-
Seth Brenith authored
Heap-profiler changes: Currently, a whole lot of types are all reported as just "system" in heap snapshots. With this change, we can use Torque-generated macro lists to easily report type names such as "system / BytecodeArray". Those objects still show up in a single category named "(system)" in the dev tools UI, so they don't clutter the output. For V8 developers or anybody who is interested in an extra-detailed view, this change also includes a runtime flag that instructs V8 to upgrade nodes of type kHidden to type kNative. After a snapshot is collected with this flag enabled, the dev tools UI then shows each internal object type separately. Torque changes: Currently, Torque emits several macro lists containing pairs of (ClassName, CLASS_NAME_TYPE) which can be used to associate instance types with Torque class names. However, some Torque classes are not included in any of these three lists. In cases like the heap profiler, it would be nice to easily generate a complete list including every instance type, so this CL includes two changes: - Include classes in TORQUE_INSTANCE_CHECKERS_MULTIPLE_FULLY_DEFINED even if they're not marked `extern`. I'm not sure what exactly we were hoping to accomplish in filtering by extern-ness, but it's simpler not to and slightly reduces clutter in a couple of files that use that macro list. - Add a fourth macro list for the previously-ignored category: classes which have their own instance type (are not `abstract`), and have subtypes, but do not have their fields defined in Torque. This list contains just a single item (HashTable), but I like the consistency of generating the full set of lists. Change-Id: Ib24953e12ed13ce353206bbec23a52d8f684dfcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2610172 Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#72138}
-
Marja Hölttä authored
This saves memory (the home object doesn't need to be stored for each method, but only once per class) and hopefully makes the home object a constant in the optimized code. Detailed documentation of the changes: https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing Bug: v8:9237 Change-Id: Ia0925bdc8bfe54cbefcba6d10f64746d63a530c7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2563275 Commit-Queue: Marja Hölttä <marja@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#72137}
-
- 16 Dec, 2020 2 commits
-
-
Sathya Gunasekaran authored
Previously, we were looking up the prototype of the receiver and checking that against %TypedArrayPrototype% before invalidating the protector cell. This is incorrect as it's possible to patch the prototype and then change the constructor property, bypassing this check. This CL adds a new instance type to prototype of all TypedArray constructors and checks the receiver against this instance type. TBR: tebbi@chromium.org Bug: v8:11274, v8:11256 Change-Id: I2ff6280e4cf820b06c5593fe4addd36f7ac656c4 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2594776 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#71799}
-
Sathya Gunasekaran authored
In the future, these instance types will be used for fast range checks rather than the current slow individual map checks. Bug: v8:11256 Change-Id: I4ad7d5259fbd46c3272a80996a5ac45a400d1f5e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2590040 Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#71791}
-
- 08 Dec, 2020 1 commit
-
-
Seth Brenith authored
Currently, all runtime C++ code generated for Torque macros all goes into a single .cc file and corresponding header. This is simple, but limits how we can use that generated code. For example, field accessors are generally expected to be inlinable at compilation time (not relying on LTO). This change updates the Torque compiler to output runtime C++ code into the same *-tq-inl.inc files that contain implementations of member functions for generated classes. All Torque macros transitively called from the top-level macros are included in the same file, to avoid any need for these generated files to #include each other. These macros are emitted within per-file namespaces to avoid multiple-definition build failures. Bug: v8:7793 Change-Id: Ic9ac3748c5020a05304773a66d7249efdc56b080 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565067 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71664}
-
- 30 Nov, 2020 1 commit
-
-
Seth Brenith authored
ScopeInfo objects generally start with three fields: flags, parameter count, and local variable count. But a single read-only ScopeInfo instance has none of those fields. This is the empty ScopeInfo, which is used for contexts that don't correspond to any scope (the native context and contexts for builtin functions). Since there is only ever a single instance of the empty ScopeInfo, the memory savings of omitting these fields is trivial, and we can simplify logic somewhat by including them. Rather than checking for length to be zero, this change introduces a new flag indicating that a ScopeInfo instance is the empty one. On its own, this change doesn't provide a whole lot of value. However, it sets us up for two further improvements, which are consistent with the goals outlined in [1]: 1. We should fully describe ScopeInfo fields in Torque. Getting rid of the requirement to check for emptiness would substantially simplify the indexed field expressions. 2. ScopeInfo shouldn't inherit from FixedArray, and shouldn't begin with a `length` field when the length can be computed from the other fields. This would save a small amount of heap memory and avoid any possibility of a mismatch between the two ways of computing the length. [1] https://docs.google.com/document/d/1tiGK7_lubxPHnInI2vscUwMHfadn8gIEa1apmI8HxR4/edit#heading=h.n63k76b3zfwa Bug: v8:8952 Change-Id: I018127698a5d91fb2a91684bc3aec2e27ee27c41 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2561598Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71500}
-
- 20 Nov, 2020 1 commit
-
-
Leszek Swirski authored
Because of LocalHeap safepoints, our existing assert scopes don't necessarily maintain the same guarantees as desired. In particular, DisallowHeapAllocation no longer guarantees that objects don't move. This patch transitions DisallowHeapAllocation to DisallowGarbageCollection, to ensure that code using this scope is also protected against safepoints. Change-Id: I0411425884f6849982611205fb17bb072881c722 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540547 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71319}
-
- 19 Nov, 2020 1 commit
-
-
Frank Emrich authored
This CL adds partial support for objects whose slow mode dictionaries are OrderedNameDictionaries. This is the case for all slow mode objects if V8_DICT_MODE_PROTOTYPES is enabled. In particular, this part contains the remaining fixes to runtime code, except for the class templating logic, which follows in a later CL. Bug: v8:7569 Change-Id: Ib4d08d7d352125709ca916dfc75018dabf71b0cd Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2540549Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Peter Marshall <petermarshall@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Igor Sheludko <ishell@chromium.org> Commit-Queue: Frank Emrich <emrich@google.com> Cr-Commit-Position: refs/heads/master@{#71275}
-
- 16 Nov, 2020 1 commit
-
-
Igor Sheludko authored
... and use Name::hash() where the hash is expected to be computed. In particular, when we are dealing with internalized strings or symbols. Bug: v8:11074 Change-Id: Ida22f134fee0ddf2c9b962d1bcca6aa0b632af5f Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529451Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#71200}
-
- 13 Nov, 2020 1 commit
-
-
Georg Neis authored
Bug: v8:7790 Change-Id: I4b6ef907c66bdc0a327d211db2f86ebb75f969a7 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536638Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Cr-Commit-Position: refs/heads/master@{#71183}
-
- 11 Nov, 2020 1 commit
-
-
Daniel Clark authored
Code review follow-ups from: Plumb import assertions through SourceTextModuleDescriptor's ModuleRequestMap Address a few bits of code review feedback that came in after landing https://chromium-review.googlesource.com/c/v8/v8/+/2493060: - Add ModuleRequest:kAssertionEntrySize and use in place of a numeric literal. - Get rid of ModuleRequestLocation and separate module_request_positions FixedArray, and merge these into AstModuleRequest and v8::internal::ModuleRequest. Change-Id: If6d628d29bfa6fbd9933c6cdaa706623128ccc5d Bug: v8:10958 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2530478Reviewed-by:
Marja Hölttä <marja@chromium.org> Reviewed-by:
Camillo Bruni <cbruni@chromium.org> Commit-Queue: Dan Clark <daniec@microsoft.com> Cr-Commit-Position: refs/heads/master@{#71125}
-
- 10 Nov, 2020 2 commits
-
-
Camillo Bruni authored
By keeping the SharedFunctionInfo around for modules with the kErrored status, we don't need the additional script field anymore. The script can thus be always accessed indirectly through the code object. Removing the script field fixes context serialization of modules. Bug: v8:11073 Change-Id: I9bb3c6b129a41e9d708547ceeb35e6d921c8eea0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2504256 Commit-Queue: Camillo Bruni <cbruni@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#71096}
-
Daniel Clark authored
This change plumbs import assertions from SourceTextModuleDescriptor's ModuleRequestMap into SourceTextModuleInfo via a new ModuleRequest type, where previously there had been only the specifier. SourceTextModuleDescriptor::module_map now deduplicates module requests using the specifier and the import assertions. Continuing to use the specifier alone would cause a loss of information in the event that a module imports from the same specifier multiple times using different sets of assertions. Failing to deduplicate at all would result in multiple requests for statements like `import {a,b,c} from "foo.js"`, which would be a potential performance issue. See design doc at https://docs.google.com/document/d/1yuXgNHSbTAPubT1Mg0JXp5uTrfirkvO1g5cHHCe-LmY for more detail on this decision. v8::internal::ModuleRequest holds the assertions as an array of the form [key1, value1, position1, key2, value2, assertion2, ...]. However the parser still needs to use a map, since duplicate assertion keys need to be detected at parse time. A follow-up change will ensure that assertions are sorted using a proper lexicographic sort. Bug: v8:10958 Change-Id: Iff13fb9a37d58fc1622cd3cce78925ad2b7a14bb Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2493060 Commit-Queue: Dan Clark <daniec@microsoft.com> Reviewed-by:
Adam Klein <adamk@chromium.org> Reviewed-by:
Marja Hölttä <marja@chromium.org> Cr-Commit-Position: refs/heads/master@{#71066}
-
- 09 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
This is a reland of 26f10ecd Change compared to original CL: The deserializer changes StrongDescriptorArray to DescriptorArray. Since this CL uses separate BodyDescriptors for the two kinds of descriptor arrays, this caused a DCHECK failure when the deserializer changes the map while the object is visited from the concurrent marking thread. Fix this by disabling the corresponding checks. Original change's description: > [torque] allow exported classes with custom C++ class > > Introduce a new annotation @customCppClass that can be used for > non-extern @export classes, that is, generate everything, remove > boilerplate from all the internal lists and switches, but allow > a custom C++ class, which in turn also allows overwriting the generated > print and verify functions. > > Port DescriptorArray and StrongDescriptorArray as an example. > > Bug: v8:7793 > Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70989} Bug: v8:7793 Change-Id: I7505fb111896991d16d7d113704c8c3676669f34 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2526383Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#71048}
-
- 05 Nov, 2020 2 commits
-
-
Michael Achenbach authored
This reverts commit 26f10ecd. Reason for revert: GC stress failures: https://crbug.com/v8/11114 Original change's description: > [torque] allow exported classes with custom C++ class > > Introduce a new annotation @customCppClass that can be used for > non-extern @export classes, that is, generate everything, remove > boilerplate from all the internal lists and switches, but allow > a custom C++ class, which in turn also allows overwriting the generated > print and verify functions. > > Port DescriptorArray and StrongDescriptorArray as an example. > > Bug: v8:7793 > Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0 > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687 > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > Reviewed-by: Nico Hartmann <nicohartmann@chromium.org> > Reviewed-by: Seth Brenith <seth.brenith@microsoft.com> > Commit-Queue: Tobias Tebbi <tebbi@chromium.org> > Cr-Commit-Position: refs/heads/master@{#70989} TBR=ulan@chromium.org,tebbi@chromium.org,seth.brenith@microsoft.com,nicohartmann@chromium.org Change-Id: I4631db66a76f41cf62b400e8ee64df27e641a320 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: v8:7793,v8:11114 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2521911Reviewed-by:
Michael Achenbach <machenbach@chromium.org> Commit-Queue: Michael Achenbach <machenbach@chromium.org> Cr-Commit-Position: refs/heads/master@{#70994}
-
Tobias Tebbi authored
Introduce a new annotation @customCppClass that can be used for non-extern @export classes, that is, generate everything, remove boilerplate from all the internal lists and switches, but allow a custom C++ class, which in turn also allows overwriting the generated print and verify functions. Port DescriptorArray and StrongDescriptorArray as an example. Bug: v8:7793 Change-Id: I744e52fb4102ac49c0097f1c95bb17d301975bf0 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489687Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70989}
-
- 03 Nov, 2020 1 commit
-
-
Jakob Gruber authored
Minor refactors to improve readability and consistency between FeedbackVectorSpec and FeedbackMetadata: - Rename FeedbackVectorSpec::slots to slot_count. - Rename FeedbackVectorSpec::closure_feedback_cells to create_closure_slot_count, likewise all related fields. - Store FeedbackVectorSpec::slot_kinds_ as an array of FeedbackSlotKind. Bug: v8:8888 Change-Id: I3a45177163d1484b1625de8dfba5c6c05cfc426d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2512908Reviewed-by:
Mythri Alle <mythria@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Michael Stanton <mvstanton@chromium.org> Commit-Queue: Michael Stanton <mvstanton@chromium.org> Auto-Submit: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70943}
-
- 02 Nov, 2020 1 commit
-
-
Tobias Tebbi authored
Drive-by fixes: - Use constexpr types to determine C++ type names. - Fix factory constructors to not skip write barriers in old generation. Change-Id: I0ebbfd56c06ad41d02836fb48531ae7eded166bf Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2400994Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70921}
-
- 29 Oct, 2020 1 commit
-
-
Nico Hartmann authored
This is the 1st step in series of CLs to move the SharedFunctionInfo class to kNeverSerialized and make it concurrently accessible from the background thread. This CL: * Enables direct heap reads for the most basic members of SFI if FLAG_turbo_direct_heap_reads is enabled. * Adds synchronization to SharedFunctionInfo::script_or_debug_info. Bug: v8:7790 Change-Id: Ia7d28033e9053aae5771b1b9b174de40f194534d Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461238Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Commit-Queue: Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#70877}
-
- 28 Oct, 2020 1 commit
-
-
Tobias Tebbi authored
This CL splits the class definitions per .tq file, to realize the following relationship: A class defined in src/objects/foo.tq has a C++ definition in src/objects/foo.h. Torque then generates: - torque-generated/src/objects/foo-tq.inc An include file (no proper header) to be included in src/objects/foo.h containing the Torque-generated C++ class definition. - torque-generated/src/objects/foo-tq-inl.inc An include file (no proper header) to be included in src/objects/foo-inl.h containing inline function definitions. - torque-generated/src/objects/foo-tq.cc A source file including src/objects/foo-inl.h that contains non-inline function definitions. Advantages of this approach: - Avoid big monolithic headers and preserve the work that went into splitting objects.h - Moving a definition to Torque keeps everything in the same place from a C++ viewpoint, including a fully Torque-generated C++ class definition. - The Torque-generated include files do not need to be independent headers, necessary includes or forward declarations can just be added to the headers that include them. Drive-by changes: A bunch of definitions and files had to be moved or created to realize a consistent 1:1 relationship between .tq files and C++ headers. Bug: v8:7793 TBR: hpayer@chromium.org Change-Id: I239a89a16d0bc856a8669d7c92aeafe24a7c7663 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2470571 Commit-Queue: Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Reviewed-by:
Seth Brenith <seth.brenith@microsoft.com> Cr-Commit-Position: refs/heads/master@{#70853}
-
- 27 Oct, 2020 1 commit
-
-
Jakob Gruber authored
This CL makes the metadata offsets stored in Code headers relative to the start of the metadata section (instead of to the start of the instructions section). In a follow-up, metadata for embedded builtins will be moved from the .text section (with r-x or --x permissions) to the .rodata section (with r-- permissions). Drive-by: Simplify invariants around section alignment. A new invariant is that the end of the instruction section is aligned to Code::kMetadataAlignment. Drive-by: Ensure trampoline Code objects contain no metadata (metadata offsets all refer to the off-heap metadata section). Tbr: dinfuehr@chromium.org Bug: v8:11036 Change-Id: Idd0980913bbde9d3d1946b558e3ca58ec6356fcc Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491036Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70788}
-
- 22 Oct, 2020 2 commits
-
-
Victor Gomes authored
Since JS arguments are always reversed now (https://crrev.com/c/2466116), the logic for skipping the arguments adapter is dead. It has been subsumed by the complete removal of the adaptor frame (https://crrev.com/c/2440098). Doc: bit.ly/v8-faster-calls-with-arguments-mismatch Change-Id: Ia02e0807b7d23a9de371650fa6357113e409d338 Bug: v8:10201 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2489684Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Commit-Queue: Victor Gomes <victorgomes@chromium.org> Cr-Commit-Position: refs/heads/master@{#70704}
-
Jakob Gruber authored
No major functional changes in this CL, mostly it moves code around to make follow-up CLs less messy. - Document Code layout. - New concepts: 'body' and 'metadata' areas of Code objects. The metadata area contains metadata tables, the body area includes both instructions and metadata (this is currently the 'instructions' area). Add accessors for these new areas. - An interesting detail: embedded builtins will have non-adjacent instruction and metadata areas, thus a concept of 'body' doesn't make sense there. - Also add raw_instruction_X_future accessors; these are used where we are actually interested in the instructions range, not the entire body. In a follow-up, current raw_instruction_X accessors will be replaced by raw_body_X, and raw_instruction_X_future by raw_instruction_X. Bug: v8:11036 Change-Id: I1d85146b652e0c097c3602d4db1862d5d3898a7e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2491023 Commit-Queue: Jakob Gruber <jgruber@chromium.org> Reviewed-by:
Clemens Backes <clemensb@chromium.org> Reviewed-by:
Dominik Inführ <dinfuehr@chromium.org> Reviewed-by:
Leszek Swirski <leszeks@chromium.org> Cr-Commit-Position: refs/heads/master@{#70701}
-
- 16 Oct, 2020 2 commits
-
-
Igor Sheludko authored
... and add respective regression tests. This CL also adds similar regression tests for TransitionArray but it doesn't have the same issue as DescriptorArray. Bug: chromium:1133527 Change-Id: I668a90f126d76af0a39816ce8697cb29bc65d01b Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2465833Reviewed-by:
Toon Verwaest <verwaest@chromium.org> Commit-Queue: Igor Sheludko <ishell@chromium.org> Cr-Commit-Position: refs/heads/master@{#70570}
-
Pierre Langlois authored
Executable V8 pages include 3 reserved OS pages: one for the writable header and two as guards. On systems with 64k OS pages, the amount of allocatable space left for objects can then be quite smaller than the page size, only 64k for each 256k page. This means regular code objects cannot be larger than 64k, while the maximum regular object size is fixed to 128k, half of the page size. As a result code object never reach this limit and we can end up filling regular pages with few large code objects. To fix this, we change the maximum code object size to be runtime value, set to half of the allocatable space per page. On systems with 64k OS pages, the limit will be 32k. Alternatively, we could increase the V8 page size to 512k on Arm64 linux so we wouldn't waste code space. However, systems with 4k OS pages are more common, and those with 64k pages tend to have more memory available so we should be able to live with it. Bug: v8:10808 Change-Id: I5d807e7a3df89f1e9c648899e9ba2f8e2648264c Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2460809Reviewed-by:
Igor Sheludko <ishell@chromium.org> Reviewed-by:
Georg Neis <neis@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com> Cr-Commit-Position: refs/heads/master@{#70569}
-
- 15 Oct, 2020 1 commit
-
-
Javad Amiri authored
Bug: v8:9533 Change-Id: I912bd5acd2cdb4c9d111711d17a01ba635b76660 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2463006 Commit-Queue: Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70523}
-
- 13 Oct, 2020 1 commit
-
-
Seth Brenith authored
This change updates verifier generation to: - Fix a bug I introduced in https://crrev.com/c/2047399 that caused values within struct-typed fields to not get verified - Support indexed fields with start offsets that are not known at compile time - Support indexed fields with complex length expressions Bug: v8:7793 Change-Id: I5ae8803fce59abae0989fcb094bd9692cd88e38e Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2461456 Commit-Queue: Seth Brenith <seth.brenith@microsoft.com> Reviewed-by:
Tobias Tebbi <tebbi@chromium.org> Cr-Commit-Position: refs/heads/master@{#70490}
-
- 08 Oct, 2020 1 commit
-
-
Georg Neis authored
Bug: v8:7790 Change-Id: I1ffb2289f613a03d0246db2d66c3caaf0e4d6d2a Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448796 Auto-Submit: Georg Neis <neis@chromium.org> Commit-Queue: Georg Neis <neis@chromium.org> Reviewed-by:
Ross McIlroy <rmcilroy@chromium.org> Reviewed-by:
Santiago Aboy Solanes <solanes@chromium.org> Reviewed-by:
Nico Hartmann <nicohartmann@chromium.org> Cr-Commit-Position: refs/heads/master@{#70406}
-
- 07 Oct, 2020 2 commits
-
-
Camillo Bruni authored
Allocating in the right spot leaves the Module in an invalid state. Do allocations before resetting a module. Drive-by-fix: make module verification check failures easier to debug. Bug: v8:10985 Change-Id: I6fc32c96441958755bfb32b3004e1bb616dc7d98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452533Reviewed-by:
Victor Gomes <victorgomes@chromium.org> Commit-Queue: Camillo Bruni <cbruni@chromium.org> Cr-Commit-Position: refs/heads/master@{#70369}
-
Leszek Swirski authored
This relands commit 3f4e9bbe. which was a reland of c4a062a9 which was a reland of 28a30c57 which was a reland of 5d7a29c9 The change had an issue that embedders implementing heap tracing (e.g. Unified Heap with Blink) could be passed an uninitialized pointer if marking happened during deserialization of an object containing such a pointer. Because of the 0xdeadbed0 uninitialized filler value, these embedders would then receive the value 0xdeadbed0deadbed0 as the 'pointer', and crash on dereference. There is, however, special handling already for null pointers in heap tracing, also for dealing with not-yet initialized values. So, we can make the uninitialized Smi filler be 0x00000000, and that will make such embedded fields have a nullptr representation, making them follow the normal uninitialized value bailouts. In addition, it relands the following dependent changes, which are relanding unchanged and are followup performance improvements. Relanding them in the same change should allow for cleaner reverts should they be needed. This relands commit 76ad3ab5 [identity-map] Change resize heuristic This relands commit 77cc96aa [identity-map] Cache the calculated Hash This relands commit bee5b996 [serializer] Remove Deserializer::Initialize This relands commit c8f73f22 [serializer] Cache instance type in PostProcessNewObject This relands commit 4e7c99ab [identity-map] Remove double-lookups in IdentityMap Original change's description: > Reland^3 "[serializer] Allocate during deserialization" > > This is a reland of c4a062a9 > which was a reland of 28a30c57 > which was a reland of 5d7a29c9 > > Fixes TSAN errors from non-atomic writes in the deserializer. Now all > writes are (relaxed) atomic. > > Original change's description: > > Reland^2 "[serializer] Allocate during deserialization" > > > > This is a reland of 28a30c57 > > which was a reland of 5d7a29c9 > > > > The crashes were from calling RegisterDeserializerFinished on a null > > Isolate pointer, for a deserializer that was never initialised > > (specifically, ReadOnlyDeserializer when ROHeap is shared). > > > > Original change's description: > > > Reland "[serializer] Allocate during deserialization" > > > > > > This is a reland of 5d7a29c9 > > > > > > This reland shuffles around the order of checks in Heap::AllocateRawWith > > > to not check the new space addresses until it's known that this is a new > > > space allocation. This fixes an UBSan failure during read-only space > > > deserialization, which happens before the new space is initialized. > > > > > > It also fixes some issues discovered by --stress-snapshot, around > > > serializing ThinStrings (which are now elided as part of serialization), > > > handle counts (I bumped the maximum handle count in that check), and > > > clearing map transitions (the map backpointer field needed a Smi > > > uninitialized value check). > > > > > > Original change's description: > > > > [serializer] Allocate during deserialization > > > > > > > > This patch removes the concept of reservations and a specialized > > > > deserializer allocator, and instead makes the deserializer allocate > > > > directly with the Heap's Allocate method. > > > > > > > > The major consequence of this is that the GC can now run during > > > > deserialization, which means that: > > > > > > > > a) Deserialized objects are visible to the GC, and > > > > b) Objects that the deserializer/deserialized objects point to can > > > > move. > > > > > > > > Point a) is mostly not a problem due to previous work in making > > > > deserialized objects "GC valid", i.e. making sure that they have a valid > > > > size before any subsequent allocation/safepoint. We now additionally > > > > have to initialize the allocated space with a valid tagged value -- this > > > > is a magic Smi value to keep "uninitialized" checks simple. > > > > > > > > Point b) is solved by Handlifying the deserializer. This involves > > > > changing any vectors of objects into vectors of Handles, and any object > > > > keyed map into an IdentityMap (we can't use Handles as keys because > > > > the object's address is no longer a stable hash). > > > > > > > > Back-references can no longer be direct chunk offsets, so instead the > > > > deserializer stores a Handle to each deserialized object, and the > > > > backreference is an index into this handle array. This encoding could > > > > be optimized in the future with e.g. a second pass over the serialized > > > > array which emits a different bytecode for objects that are and aren't > > > > back-referenced. > > > > > > > > Additionally, the slot-walk over objects to initialize them can no > > > > longer use absolute slot offsets, as again an object may move and its > > > > slot address would become invalid. Now, slots are walked as relative > > > > offsets to a Handle to the object, or as absolute slots for the case of > > > > root pointers. A concept of "slot accessor" is introduced to share the > > > > code between these two modes, and writing the slot (including write > > > > barriers) is abstracted into this accessor. > > > > > > > > Finally, the Code body walk is modified to deserialize all objects > > > > referred to by RelocInfos before doing the RelocInfo walk itself. This > > > > is because RelocInfoIterator uses raw pointers, so we cannot allocate > > > > during a RelocInfo walk. > > > > > > > > As a drive-by, the VariableRawData bytecode is tweaked to use tagged > > > > size rather than byte size -- the size is expected to be tagged-aligned > > > > anyway, so now we get an extra few bits in the size encoding. > > > > > > > > Bug: chromium:1075999 > > > > Change-Id: I672c42f553f2669888cc5e35d692c1b8ece1845e > > > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2404451 > > > > Commit-Queue: Leszek Swirski <leszeks@chromium.org> > > > > Reviewed-by: Jakob Gruber <jgruber@chromium.org> > > > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org> > > > > Cr-Commit-Position: refs/heads/master@{#70229} Bug: chromium:1075999 Change-Id: Ib514a4ef16bd02bfb60d046ecbf8fae1ead64a98 Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2452689 Commit-Queue: Leszek Swirski <leszeks@chromium.org> Reviewed-by:
Ulan Degenbaev <ulan@chromium.org> Reviewed-by:
Jakob Gruber <jgruber@chromium.org> Cr-Commit-Position: refs/heads/master@{#70366}
-