When a function .prototype is accessed for the first time during
side-effect-free evaluation (Runtime.evaluate), GetFunctionPrototype
lazily allocates the .prototype object (JSObject) and its initial Map.
Previously, GetFunctionPrototype disabled temporary object tracking
(DisableTemporaryObjectTracking) around this allocation so that
mutations to the prototype of a permanent function would not be
misidentified as temporary. However, when tracking was disabled,
AllocationEvent simply returned without taking any action. If the newly
allocated prototype object or its Map reused memory addresses belonging
to dead temporary objects, those stale memory ranges remained in
TemporaryObjectsTracker::regions_. Consequently, HasObject incorrectly
identified the permanent function prototype as a temporary object,
allowing its prototype to be polluted during debug evaluation without
triggering a side-effect check error.
To fix this simply and robustly:
1. When TemporaryObjectsTracker::AllocationEvent is invoked while
tracking is disabled (disabled == true), it explicitly calls
RemoveFromRegions(addr, addr + size). This clears out any stale
overlapping memory ranges from dead temporary objects while
ensuring the new allocation is not added to regions_.
2. JSFunction::GetFunctionPrototype conditionally enters
DisableTemporaryObjectTracking when the parent JSFunction (function)
is not a temporary object (!isolate->debug()->IsTemporaryObject(function)).
TAG=agy
CONV=b7469c8c-dfea-4bf5-ae4e-e442ac035cad
Bug: 532099983
Change-Id: I9586b1db45a768dc1f3f7cde10c4a7f72fe1b661
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/8064726
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#108584}
We have three failure classes:
1. Side effects test: the debugger side effects test automatically tests
all Date properties for side effects. It understandably fails on the
builtin Date.toTemporalInstant since it can't be run in pure
bytecode.
2. format-range tests: There is a specific order of operations where
Intl.DateTimeFormat must run ToNumber first. Temporal patches the
Intl spec and the patch was not implemented 100% correctly.
3. comma-compat-on: We have a special flag to restore older ICU4C
behavior, which was only in the pre-Temporal code.
Bug: 401065166
Change-Id: Ie1ced463a2e5710b2664efefbd61d5a06a6a6964
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/7111926
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Manish Goregaokar <manishearth@google.com>
Cr-Commit-Position: refs/heads/main@{#103504}
This is a reland of commit d2ab66c2a9
Changes from original:
- The test inspector/debugger/set-breakpoint-after-gc relies on
precise garbage collection and may fail if conservative stack
scanning is used. We call GC multiple times to ensure the weak
reference hold by the script is eventually collected.
- Allow reading a ContextCell when printing debug stack frame.
Original change's description:
> [contexts] Unify context accessors after ContextCells
>
> The introduction of ContextCells removed the need for special handling
> for ScriptContext (which previously used a side table for
> let/const tracking and mutable numbers).
>
> This change refactors the context access logic:
> - Internal get/set accessors are now protected to the Context class.
> - External access should use the new functions:
> - Get/Set: A safe (though potentially slower)
> function for accessing elements in any context.
> - GetNoCell/SetNoCell: A faster function that verifies the
> element being accessed is not a ContextCell.
>
> Additionally, related bytecode operations and optimizer functions have
> been renamed for consistency with these changes.
>
> Bug: 408128754
>
> Change-Id: I785281ab6f13b0ae65578eb5d2f0a5750457ab5e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6450582
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#99844}
Bug: 408128754, 40789559
Change-Id: I78a3a99a4f364ed78965fbed56a084d38382d2fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6479814
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#99865}
This reverts commit d2ab66c2a9.
Reason for revert: Breaking CSS
https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20css%20-%20debug/12484/overview
Original change's description:
> [contexts] Unify context accessors after ContextCells
>
> The introduction of ContextCells removed the need for special handling
> for ScriptContext (which previously used a side table for
> let/const tracking and mutable numbers).
>
> This change refactors the context access logic:
> - Internal get/set accessors are now protected to the Context class.
> - External access should use the new functions:
> - Get/Set: A safe (though potentially slower)
> function for accessing elements in any context.
> - GetNoCell/SetNoCell: A faster function that verifies the
> element being accessed is not a ContextCell.
>
> Additionally, related bytecode operations and optimizer functions have
> been renamed for consistency with these changes.
>
> Bug: 408128754
>
> Change-Id: I785281ab6f13b0ae65578eb5d2f0a5750457ab5e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6450582
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#99844}
Bug: 408128754
Change-Id: I8bcbe024f563e8e2af88ec439ebfe5777e43b158
No-Tree-Checks: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6478800
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Shu-yu Guo <syg@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#99846}
The introduction of ContextCells removed the need for special handling
for ScriptContext (which previously used a side table for
let/const tracking and mutable numbers).
This change refactors the context access logic:
- Internal get/set accessors are now protected to the Context class.
- External access should use the new functions:
- Get/Set: A safe (though potentially slower)
function for accessing elements in any context.
- GetNoCell/SetNoCell: A faster function that verifies the
element being accessed is not a ContextCell.
Additionally, related bytecode operations and optimizer functions have
been renamed for consistency with these changes.
Bug: 408128754
Change-Id: I785281ab6f13b0ae65578eb5d2f0a5750457ab5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/6450582
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#99844}
Some methods were not allowlisted because in the past, they were
implemented as JS builtins and there were side-effects due to creating
an i18n cache object.
Some other methods were not allowlisted because they run regexps, which
can affect RegExp.$1 etc – that has since then been worked around.
For String.{match, matchAll, replace, replaceAll, split, search} we
invalidate the protector cell to avoid the fast path that inlines calls
to RegExp.prototype[Symbol.*].
Bug: 351769842
Change-Id: I2e5276b81d5b48488fc716d183a7ffa74a225604
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5720968
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#95118}
and dispose method
This CL adds DisposableStack constructor, use() and dispose() methods
as developer exposed methods. Also, this CL fixed the use
of `using` keyword with `null` and `undefined` and adds tests for them.
Bug: 42203506
Change-Id: If50b9e33d9cbb3de2be41dc81e656d9d202b8fa8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/5498999
Commit-Queue: Rezvan Mahdavi Hezaveh <rezvan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/main@{#93807}
The special handling with explicit side effect check is not necessary, since we have a general mechanism via
Debug::PerformSideEffectCheckForObject.
Also added a test to make sure Array.prototype.fill triggers side
effects for an existing array but does not for a newly-created array.
R=syg@chormium.org
Change-Id: I44a82823bd35bee9a900468832c3e79c3d15a121
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4624438
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#88399}
... instead of the native data property.
This fixes the JS spec violation when reading a data property does not
expect any observable side effects. For example, OrdinaryGetOwnProperty
(see https://tc39.es/ecma262/#sec-ordinarygetownproperty, step 4a).
Differences to previous behaviour:
- Error.stack is defined as a JavaScript accessor property.
- all Error objects get a private "error_stack_symbol" field where
the captured stack trace is stored (previously it was added only when
the error was actually thrown which caused unnecessary transitions).
- Error.captureStackTrace(obj) adds public "stack" accessor property
and private "error_stack_symbol" property to given "obj".
- calling "stack" getter/setter is a no-op in case receiver is not an
"Error-like" object, i.e. it doesn't have a "error_stack_symbol"
property and it doesn't have a prototype with such a property (the
lookup stops at JSProxy or interceptor).
- the "stack" getter walks the prototype chain from receiver until it
finds a holder with the "error_stack_symbol" property which is then
used for computing the result.
This is slightly different from the previous behaviour in case
receiver's prototype chain contains multiple error objects.
- the "stack" setter walks the prototype chain from receiver until it
finds a holder with the "error_stack_symbol" property and stores the
value there.
Drive-by: handle lazy accessor pairs in ObjectVisitorDeepFreezer.
Bug: v8:5962
Change-Id: I109d6fbbbdb9588d13ca86d217efd9a4a11d8447
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4459251
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#87286}
For background and reasoning, see
https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit
This is the first step towards pulling the DefineNamedOwn operation out
of StoreIC.
Summary of the renamed identifiers:
Bytecodes:
- StaNamedProperty -> SetNamedProperty: calls StoreIC and emitted for
normal named property sets like obj.x = 1.
- StaNamedOwnProperty -> DefineNamedOwnProperty: calls
DefineNamedOwnIC (previously StoreOwnIC), and emitted for
initialization of named properties in object literals and named
public class fields.
- StaKeyedProperty -> SetKeyedProperty: calls KeyedStoreIC and emitted
for keyed property sets like obj[x] = 1.
- StaKeyedPropertyAsDefine -> DefineKeyedOwnProperty: calls
DefineKeyedOwnIC (previously KeyedDefineOwnIC) and emitted for
initialization of private class fields and computed public class
fields.
- StaDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral: calls
DefineKeyedOwnPropertyInLiteral runtime function (previously
DefineDataPropertyInLiteral) and emitted for initialization of keyed
properties in object literals and static class initializers. (note
that previously the StoreDataPropertyInLiteral runtime function name
was taken by object spreads and array literal creation instead)
- LdaKeyedProperty -> GetKeyedProperty, LdaNamedProperty ->
GetNamedProperty, LdaNamedPropertyFromSuper ->
GetNamedPropertyFromSuper: we drop the Sta prefix for the property
store operations since the accumulator use is implicit and to make
the wording more natural, for symmetry the Lda prefix for the
property load operations is also dropped.
opcodes:
- (JS)StoreNamed -> (JS)SetNamedProperty: implements set semantics for
named properties, compiled from SetNamedProperty (previously
StaNamedProperty) and lowers to StoreIC or Runtime::kSetNamedProperty
- (JS)StoreNamedOwn -> (JS)DefineNamedOwnProperty: implements define
semantics for initializing named own properties in object literal and
public class fields, compiled from DefineNamedOwnProperty (previously
StaNamedOwnProperty) and lowers to DefineNamedOwnIC
(previously StoreOwnIC)
- (JS)StoreProperty -> (JS)SetKeyedProperty: implements set semantics
for keyed properties, only compiled from SetKeyedProperty(previously
StaKeyedProperty) and lowers to KeyedStoreIC
- (JS)DefineProperty -> (JS)DefineKeyedOwnProperty: implements define
semantics for initialization of private class fields and computed
public class fields, compiled from DefineKeyedOwnProperty (previously
StaKeyedPropertyAsDefine) and calls DefineKeyedOwnIC (previously
KeyedDefineOwnIC).
- (JS)StoreDataPropertyInLiteral ->
(JS)DefineKeyedOwnPropertyInLiteral: implements define semantics for
initialization of keyed properties in object literals and static
class initializers, compiled from DefineKeyedOwnPropertyInLiteral
(previously StaDataPropertyInLiteral) and calls the
DefineKeyedOwnPropertyInLiteral runtime function (previously
DefineDataPropertyInLiteral).
Runtime:
- DefineDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral:
following the bytecode/opcodes change, this is used by
DefineKeyedOwnPropertyInLiteral (previously StaDataPropertyInLiteral)
for object and class literal initialization.
- StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral_Simple:
it's just a simplified version of DefineDataPropertyInLiteral that
does not update feedback or perform function name configuration.
This is used by object spread and array literal creation. Since we
are renaming DefineDataPropertyInLiteral to
DefineKeyedOwnPropertyInLiteral, rename this simplified version with
a `_Simple` suffix. We can consider merging it into
DefineKeyedOwnPropertyInLiteral in the future. See
https://docs.google.com/document/d/1jvSEvXFHRkxg4JX-j6ho3nRqAF8vZI2Ai7RI8AY54gM/edit?disco=AAAAQQIz6mU
- Other changes following the bytecode/IR changes
IC:
- StoreOwn -> DefineNamedOwn: used for initialization of named
properties in object literals and named public class fields.
- StoreOwnIC -> DefineNamedOwnIC
- StoreMode::kStoreOwn -> StoreMode::kDefineNamedOwn
- StoreICMode::kStoreOwn -> StoreICMode::kDefineNamedOwn
- IsStoreOwn() -> IsDefineNamedOwn()
- DefineOwn -> DefineKeyedOwn: IsDefineOwnIC() was already just
IsDefineKeyedOwnIC(), and IsAnyDefineOwn() includes both named and
keyed defines so we don't need an extra generic predicate.
- StoreMode::kDefineOwn -> StoreMode::kDefineKeyedOwn
- StoreICMode::kDefineOwn -> StoreICMode::kDefineKeyedOwn
- IsDefineOwn() -> IsDefineKeyedOwn()
- IsDefineOwnIC() -> IsDefineKeyedOwnIC()
- Removing IsKeyedDefineOwnIC() as its now a duplicate of
IsDefineKeyedOwnIC()
- KeyedDefineOwnIC -> DefineKeyedOwnIC,
KeyedDefineOwnGenericGenerator() -> DefineKeyedOwnGenericGenerator:
make the ordering of terms more consistent
- IsAnyStoreOwn() -> IsAnyDefineOwn(): this includes the renamed and
DefineNamedOwn and DefineKeyedOwn. Also is_any_store_own() is
removed since it's just a duplicate of this.
- IsKeyedStoreOwn() -> IsDefineNamedOwn(): it's unclear where the
"keyed" part came from, but it's only used when DefineNamedOwnIC
(previously StoreOwnIC) reuses KeyedStoreIC, so rename it accordingly
Interpreter & compiler:
- BytecodeArrayBuilder: following bytecode changes
- StoreNamedProperty -> SetNamedProperty
- StoreNamedOwnProperty -> DefineNamedOwnProperty
- StoreKeyedProperty -> SetKeyedProperty
- DefineKeyedProperty -> DefineKeyedOwnProperty
- StoreDataPropertyInLiteral -> DefineKeyedOwnPropertyInLiteral
- FeedbackSlotKind:
- kDefineOwnKeyed -> kDefineKeyedOwn: make the ordering of terms more
consistent
- kStoreOwnNamed -> kDefineNamedOwn: following the IC change
- kStoreNamed{Sloppy|Strict} -> kSetNamed{Sloppy|Strict}: only
used in StoreIC for set semantics
- kStoreKeyed{Sloppy|Strict} -> kSetKeyed{Sloppy|Strict}: only used
in KeyedStoreIC for set semantics
- kStoreDataPropertyInLiteral -> kDefineKeyedOwnPropertyInLiteral:
following the IC change
- BytecodeGraphBuilder
- StoreMode::kNormal, kOwn -> NamedStoreMode::kSet, kDefineOwn: this
is only used by BytecodeGraphBuilder::BuildNamedStore() to tell the
difference between SetNamedProperty and DefineNamedOwnProperty
operations.
Not changed:
- StoreIC and KeyedStoreIC currently contain mixed logic for both Set
and Define operations, and the paths are controlled by feedback. The
plan is to refactor the hierarchy like this:
```
- StoreIC
- DefineNamedOwnIC
- SetNamedIC (there could also be a NamedStoreIC if that's helpful)
- KeyedStoreIC
- SetKeyedIC
- DefineKeyedOwnIC
- DefineKeyedOwnICLiteral (could be merged into DefineKeyedOwnIC)
- StoreInArrayLiteralIC
- ...
```
StoreIC and KeyedStoreIC would then contain helpers shared by their
subclasses, therefore it still makes sense to keep the word "Store"
in their names since they would be generic base classes for both set
and define operations.
- The Lda and Sta prefixes of bytecodes not involving object properties
(e.g. Ldar, Star, LdaZero) are kept, since this patch focuses on
property operations, and distinction between Set and Define might be
less relevant or nonexistent for bytecodes not involving object
properties. We could consider rename some of them in future patches
if that's helpful though.
Bug: v8:12548
Change-Id: Ia36997b02f59a87da3247f20e0560a7eb13077f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3481475
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/main@{#79409}
While working on C++ debug evaluate, we found that several builtins and
intrinsics aren't marked as side effect free, although they are clearly
side effect free, and that breaks the C++ side effect free evaluation.
- %DefineClass() and %TypedArray%.of(), and
- various WebAssembly getters ("buffer", "exports" and "length") as
well as the C++ functions for the debug proxy.
Also-By: pfaffe@chromium.org
Bug: chromium:1137514
Change-Id: Iebd333dc2014f1ad218908f64c9199c157dc08b5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565135
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71498}
Math.random, while technically not having any effects which modify the
surrounding JS state, does observably change between a no-side-effects
evaluation and an actual evaluation, and can cause confusion.
Change-Id: I4a41ac6fd3153a14245d5940fe52ada43ca05e0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2207805
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Gus Caplan <me@gus.host>
Cr-Commit-Position: refs/heads/master@{#67927}
This fixes the DevTools console preview when using REPL mode.
AsyncFunction* intriniscs are side-effect free and marking them as such
is correct.
Bug: chromium:1043151
Change-Id: Ie0c36507b98b0c12f3d627c34102c04c27358ff2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2010106
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65876}
Enable --harmony-string-matchall by default.
String.prototype.matchAll behaves similarly to
String.prototype.match, but returns a full regexp
result object for each match in a global or sticky
regexp. This offers a simple way to iterate over
matches when access to e.g. capture groups is
needed.
const string = 'a b c';
const regex = /[ac]/g;
for (const match of string.matchAll(regex)) {
console.log(`${match[0]} at ${match.index}`);
}
// a at 0
// c at 4
More information can be found here:
https://github.com/tc39/proposal-string-matchall
Drive-by: Update debug evaluate side effect
expectations to handle String.p.matchAll and
RegExp.p[@@matchAll]
Bug: v8:6890
Change-Id: Ie3e712af66689936b7d2a15df705b792ccf06bd3
Reviewed-on: https://chromium-review.googlesource.com/c/1377774
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#58250}
This also includes ports of Array.p.toString and Array.p.toLocaleString.
Many parts of the old JS implementation are preserved, because
TypedArray.p.join still relies on it. These will be removed once
TypedArray.p.join is ported to Torque.
To simplify implementation, special handling of extremely sparse arrays
has been removed.
Performance improvements vary by array size, elements, and sparse-ness.
Some quick numbers and graphs are here:
https://docs.google.com/spreadsheets/d/125VLmRMudk8XaomLCsZQ1ewc94WCqht-8GQwU3s9BW8/edit#gid=2087673710
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.v8.try:v8_linux_noi18n_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ia4069a068403ce36676c37401d349aefc976b045
Reviewed-on: https://chromium-review.googlesource.com/c/1196693
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56699}
This is a reland of eccf186749
Original change's description:
> [interpreter] Separate bytecodes for one-shot property loads and stores
>
> Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
> for one-shot property loads and stores. This CL replaces the runtime
> calls with new bytecodes for named property load stores in one-shot code.
> the runtime calls needed extra set of consecutive registers and
> additional move instructions. This increased the size of
> bytecode-array and possibly extended the life time of objects.
> By replacing them with NoFeedback bytecodes we avoid these issues.
>
> Bug: v8:8072
> Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
> Reviewed-on: https://chromium-review.googlesource.com/1196725
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Chandan Reddy <chandanreddy@google.com>
> Cr-Commit-Position: refs/heads/master@{#56211}
Bug: v8:8072
Change-Id: Ie8e52b37daf35c7bc08bb910d7b15a9b783354e4
Reviewed-on: https://chromium-review.googlesource.com/1245742
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56266}
Create LdaNamedPropertyNoFeedback and StaNamedPropertyNoFeedback
for one-shot property loads and stores. This CL replaces the runtime
calls with new bytecodes for named property load stores in one-shot code.
the runtime calls needed extra set of consecutive registers and
additional move instructions. This increased the size of
bytecode-array and possibly extended the life time of objects.
By replacing them with NoFeedback bytecodes we avoid these issues.
Bug: v8:8072
Change-Id: I20a38a5ce9940026171d870d354787fe0b7c5a6f
Reviewed-on: https://chromium-review.googlesource.com/1196725
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Chandan Reddy <chandanreddy@google.com>
Cr-Commit-Position: refs/heads/master@{#56211}
Side effect free whitelist now
- supports 'typeof' when it performs Load operations
- runtime checks for Array.p.splice
Bug: v8:7588
Change-Id: I45bcd705f8d3f2d2ee61f018566439bf56d1bcbc
Reviewed-on: https://chromium-review.googlesource.com/1037926
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52976}
This CL allows SetPrototypeAdd and ArrayIteratorPrototypeNext
to be called on temporary objects during side effect free evaluation.
Bug: v8:7588
Change-Id: Id77848e48d98c243de91bc6c0fae5a0877e693d4
Reviewed-on: https://chromium-review.googlesource.com/998439
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52548}
This whitelists Function-related builtins used by Blink callbacks at
the DOM wrapping stage, and other BigInt methods.
Bug: chromium:810176
Change-Id: If036114cd7f133f2c30247dff836698c2eb16a51
Reviewed-on: https://chromium-review.googlesource.com/1004000
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52530}
Yang Guo
Olivier Flückiger
Manish Goregaokar
Victor Gomes
Shu-yu Guo
Rezvan Mahdavi Hezaveh
Ergün Erdoğmuş
Igor Sheludko
Joyee Cheung
Benedikt Meurer
Dan Elphick
Gus Caplan
Simon Zünd
peterwmwong
Sigurd Schneider
Creddy
Maya Lekova
Deepti Gandluri
Mathias Bynens
Erik Luo
Alexey Kozyatinskiy
Jakob Gruber