Array.of/from returned HOLEY elements kind even though their returned array can be PACKED, which made it hard to take fast paths for PACKED arrays.
This CL creates a PACKED array directly for the cases where the receiver is the default array function.
Bug: chromium:1305342
Change-Id: Id14124d029ea87dc7c9320f62087f63460acd446
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4062669
Commit-Queue: Choongwoo Han <choongwoo.han@microsoft.com>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84582}
In assertOptimized and assertUnoptimized, we can optionally pass in the
function name. We also used to pass in an optional 'sync' parameter, to
decide whether to wait for background compilations to finish before
checking state.
The sync parameter was removed in favour of explicit intrinsics, so fix
callers of assertOptimized to no longer try to set it. Also, use
function.name as the function name when no name was passed.
Change-Id: I8e98d4d02e2d097d059989ad78bf46b97b57bdca
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4000480
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84080}
When creating a character class in unicode, case-insensitive mode we use
icu::UnicodeSet::closeOver() to add all characters that case-insensitive
match the characters in the class.
According to the spec only simple case folding shall be performed for
case-insensitive unicode matching, but closeOver() adds all characters
that are equal w.r.t full case folding.
The current approach of just removing strings from the closeOver set is
not enough, as single code point characters still remain in the set if
they were equal only by performing full case folding.
E.g. the characters \u0390 and \u1FD3 both fold to the same string
"\u03B9\u0308\u0301" via full case folding, but they don't have a simple
case folding in common.
To prevent these wrong matches, we calculate the set of all characters
with close overs that are wrong according to the spec at build time and
remove them from the set before adding case-insensitive equivalent
characters.
Bug: v8:13377
Change-Id: I0252c79143f266911691331dd0e1e27044ea8cba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3952095
Commit-Queue: Patrick Thier <pthier@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83791}
Make several changes to template object caching:
* Key the cache on Script rather than SFI, so that entries stay alive
even if the SFI dies (e.g. because its parent is code flushed) but
can be resurrected (because other functions from the same script can
recreate it)
* With the above change, identify the required template object by
comparing both function literal id and feedback slot id.
* Change the cache from a linked list of CachedTemplateObjects into an
ArrayList pointing directly to the template object JSArrays.
* With CachedTemplateObjects being gone, store the function literal id
and slot id directly on the JSArray behind private symbols. Fast
path access to them in the case where the template object has the
expected map, and look them up in a slow path if the map changed
(e.g. because the template object was used as a prototype and
transitioned to a dictionary map).
Change-Id: Id715cb2fd38b9605b8e6ddf5e35336bb4f0300d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3900376
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83693}
assertEquals() compares objects by comparing each property for both
objects. This was done by using Object.keys() which however only returns
enumerable properties.
With this change also non-enumerable properties are compared.
Still, the comparison doesn't require the properties to be equal.
So, if one property is marked enumerable in one object but not the
other, the objects would still be considered equal.
This could be adapted in a follow-up CL if desired.
The prototype is still ignored for the comparison.
Change-Id: I1bb9df055bfb764ac1c02d971ac6f4a50f4a98e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876384
Commit-Queue: Matthias Liedtke <mliedtke@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83058}
Calling memset directly is faster than std::fill for multi-byte element
types.
Change-Id: I83b997740146688f87b86901825e31d6644bc25b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3687700
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80945}
To be consistent with the all the other tiers and avoid confusion, we
rename --opt to ---turbofan, and --always-opt to --always-turbofan.
Change-Id: Ie23dc8282b3fb4cf2fbf73b6c3d5264de5d09718
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3610431
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Linke <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80336}
This CL extends GetIterator to check whether the result of
calling @@iterator is JSReceiver and throw SymbolIteratorInvalid
if it's not JSReceiver.
GetIterator bytecode involves 3 steps now:
- method = GetMethod(obj, @@iterator)
- iterator = Call(method, obj)
- if(!IsJSReceiver(iterator)) throw SymbolIteratorInvalid [Added]
New Builtin: CallIteratorWithFeedbackLazyDeoptContinuation, which
is used when lazy deopt is triggered by call @@iterator.
Related spec: https://tc39.es/ecma262/#sec-getiterator.
Related doc: https://docs.google.com/document/d/1s67HC2f-4zxA_s1Bmm7dfwMFv_KDUfMiWIKkNSeQNKw/edit#heading=h.kdzv8mq4g4ks.
Bug: v8:9489
Change-Id: I17952c0f3e24e1e600ee1348809fb188c2c70f8e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3563447
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@{#80112}
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/+/3400150
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78687}
After the parameter processing, the arraybuffer may have been detached.
TypedArray copyWithin/fill should throw in that condition. TypedArray
includes should return false if the search element is not undefined.
Change-Id: If507d0efa1dafbe3dcefcd368e5ea27406bb3df8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3144315
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77103}
This is a reland of 5dde281c87,
after also fixing the ic-migrated-... test, in which an object died
too early.
Original change's description:
> [compiler] Fix a few test flakes and reenable the tests
>
> Bug: v8:12173
> Change-Id: I2983be9133f8ff4d1740e8eba05a3c29d603dfc3
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3168270
> Auto-Submit: Georg Neis <neis@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Commit-Queue: Georg Neis <neis@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76939}
Bug: v8:12173
Change-Id: If385e5c826b8470ef67f12705c5171f330f6cd57
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3171353
Auto-Submit: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76946}
Removes outdated type-error throwing on TypedArray.prototype.set
when the first argument is a number.
Bug: v8:11294
Change-Id: Ida3a46dec154b645620e2b064ded7a18de238649
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3136773
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76631}
%TypedArray.prototype% methods that receive a user callback
fn should not break in the mid-way of the iteration when the
backing array buffer was been detached. Instead, the iteration
should continue with the value set to undefined.
Notably, %TypedArray.prototype%.filter was throwing when the
backing buffer was detached during iteration. This should not
throw now.
Refs: https://github.com/tc39/ecma262/pull/2164
Bug: v8:4895
Change-Id: Ia7fab63264c8148a11f8f123b43c7b3ee0893300
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3066941
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76611}
This relands squashed CLs:
59b9aaf7db8f84d0bb8f
The revert was at crrev.com/c/2996198.
Changed: Fixed a test in which bytecode flushing caused a behavioral
change between serialized- and unserialized SFI Refs. The serialized
SFI ref kept bytecode alive while unserialized SFIs allow flushing.
The test was fixed by adding a %PrepareFunctionForOptimization
annotation.
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7790, v8:11939
Change-Id: I170f8085bd7454a2a5f2bb03c8824e2862857827
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999089
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75504}
https://github.com/tc39/ecma262/pull/1490 changed the spec so that the
"name" property of a class should be installed after "length" but before
"prototype". This CL adapts accordingly.
After this change, there is now no need for the separate code path to
set the "name" accessor at runtime. Delete the relevant runtime code as
well.
Bug: v8:8771
Change-Id: I8f809b45bf209c899cf5df76d0ebf6d9a45a6d4e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2974772
Commit-Queue: Timothy Gu <timothygu@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75340}
This isn't used outside of tests, so let's just remove it.
Change-Id: I06b7ec11911fd8ebc3bbabcba16d0c2a3fafddab
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2968413
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75220}
This CL is part of a series that implements Turbofan support for
property accesses satisfying the following conditions:
1. The holder is a dictionary mode object.
2. The holder is a prototype.
3. The access is a load.
This feature will only be enabled if the build flag
v8_dict_property_const_tracking is set.
This particular CL modifies existing mjsunit tests whose assumptions
don't hold if v8_dict_property_const_tracking is enabled. This is
done by adding special handling for the case that
%IsDictPropertyConstTrackingEnabled() holds.
Bug: v8:11248
Change-Id: Ia36be73e4659a988b2471f0c8151b0442f3a98f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2780292
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73745}
This flag enables feedback allocation heuristics to be based on the
function size. The threshold for feedback allocation is set to
12 * bytecode size to roughly mimic the allocation after 12 invocations.
We tried 4 * bytecode size earlier and there were few memory regressions
on real world pages. Speedometer improved by ~1% [1, 2]. This time
trying with a higher factor this time to see if we still have
speedometer improvements without any memory regressions.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=1177124
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=1177241
Change-Id: I39c7d4aaf90b948b07419e4598e2193b8355c067
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752150
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73369}
This is a reland of cf93071c91
Original change's description:
> [interpreter] Short Star bytecode
>
> Design doc:
> https://docs.google.com/document/d/1g_NExMT78II_KnIYNa9MvyPYIj23qAiFUEsyemY5KRk/edit
>
> This change adds 16 new interpreter opcodes, kStar0 through kStar15, so
> that we can use a single byte to represent the common operation of
> storing to a low-numbered register. This generally reduces the quantity
> of bytecode generated on web sites by 8-9%.
>
> In order to not degrade speed, a couple of other changes are required:
>
> The existing lookahead logic to check for Star after certain other
> bytecode handlers is updated to check for these new short Star codes
> instead. Furthermore, that lookahead logic is updated to contain its own
> copy of the dispatch jump rather than merging control flow with the
> lookahead-failed case, to improve branch prediction.
>
> A bunch of constants use bytecode size in bytes as a proxy for the size
> or complexity of a function, and are adjusted downward proportionally to
> the decrease in generated bytecode size.
>
> Other small drive-by fix: update generate-bytecode-expectations to emit
> \n instead of \r\n on Windows.
>
> Change-Id: I6307c2b0f5794a3a1088bb0fb94f6e1615441ed5
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2641180
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72773}
Change-Id: I1afb670c25694498b3989de615858f984a8c7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2698057
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72821}
Sparkplug is a new baseline, non-optimising second-tier compiler,
designed to fit in the compiler trade-off space between Ignition and
TurboProp/TurboFan.
Design doc:
https://docs.google.com/document/d/13c-xXmFOMcpUQNqo66XWQt3u46TsBjXrHrh4c045l-A/edit?usp=sharing
Bug: v8:11420
Change-Id: Ideb7270db3d6548eedd8337a3f596eb6f8fea6b1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2667514
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72686}
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}
This reverts commit f6450b97ec.
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/+/2653158
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72391}
Currently, feedback vectors are allocated on a fixed budget of 1024.
In some cases it might be beneficial to allocate feedback vectors based
on invocation count rather than fixed budget. For example, if we have
a large function that is only run once. This cl adds an option to
use interrupt budget based on the bytecode size. It kind of mimics
invocation count. We would allocate feedback vectors early when we
have loops which is also required.
This flag is turned off by default. In followup cl, we will enable it
and if the memory / performance tradeoff is good we might make it
default.
Change-Id: I9f7231119b5fd65fb3268e665e2e315fb2625e1b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2584960
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72371}
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}
This reverts commit 4d5b878b61.
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/+/2637215
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72142}
This implements the spec change in
https://github.com/tc39/ecma262/pull/2164
Making TA elements configurable has interaction with delete. While
the elements are configurable, they are only "deletable" via detaching
the underlying ArrayBuffer, not via `delete`. That is, `delete ta[idx]`
for an in-bounds `idx` still returns false.
Bug: v8:11281
Change-Id: I2e9348a7ec3c3239a92cc35e51b7182423736834
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2605234
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71955}
AddToDictionaryTemplate in literal-objects.cc was missing several
cases when handling the overwriting between properties with statically
known and dynamically computed names. This led to wrong enumeration
orders in class prototypes created from class templates.
Bug: v8:11158
Change-Id: I7381b4680ec533bd307a6c32d75c8a66394869df
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2536464
Commit-Queue: Frank Emrich <emrich@google.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71266}
... to --turbo-dynamic-map-checks. With the upcoming use in NCI code,
this feature is no longer used exclusively by Turboprop.
Bug: v8:8888
Change-Id: I61e01db086fd2e8566d2e2a09574be74b6e5a7bd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2546693
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71263}
The tests assert that funcs are optimized / deoptimized a certain way.
Bug: v8:9237, v8:11138
Change-Id: Ia4879e722e442be52de0bf93919eb03fecb88147
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2529136
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71087}
This reverts commit 0147db5a4a.
Reason for revert: Data races: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/34056
Original change's description:
> [super] Optimize super property access in JSNativeContextSpecialization
>
> Generalize the existing property lookup machinery
> (JSNCS::ReduceNamedAccess) to handle the case where the
> lookup_start_object and the receiver are different objects.
>
> Design doc: https://docs.google.com/document/d/1b_wgtExmJDLb8206jpJol-g4vJAxPs1XjEx95hwRboI/edit#heading=h.xqthbgih7l2l
>
> Bug: v8:9237
> Change-Id: I28b6d87ce6537acd8cf972bbe7dc6d63d581aadc
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2487122
> Commit-Queue: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#70988}
TBR=marja@chromium.org,mvstanton@chromium.org,neis@chromium.org
Change-Id: Ib5ddb919ae569fe5ddf266d986f1c8bc0fe9621a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9237
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2520908
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70992}
