Based on a CL by mvstanton@.
Bug: v8:7790,v8:12030,v8:12031,v8:12041
Change-Id: I58b75bd96c724a99133bec7d3bd6cf4e0c9be6d4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059683
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76055}
stress_flush_bytecode controls stress flushing of both bytecode and
baseline code. So rename the flag to better reflect its functionality
Bug: v8:11947
Change-Id: Ie6c124a476c3a7c6eabd1d75de030ee15fe78e32
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3062567
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76043}
Previously, when the Load IC saw a deprecated map, it would migrate to
the new map but not update the feedback vector. This would lead to a
deopt the next time the same object was seen.
With this CL, the feedback vector will be updated to the target of the
deprecated map. In order to do this, we need to mark the IC for
recomputation. Without that call, the map and handler would look the
same to IC::UpdatePolymorphicIC amd would decline to update, causing
the IC to go megamorphic instead.
Bug: v8:10816
Change-Id: I0dcf97fb278bc0b167df6ce24d5db179f599f535
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3032983
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Kevin Babbitt <kbabbitt@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#76042}
Regressed in crrev.com/152ecad8cd4d170e4091a79eaa8d70d10d94734d.
Fixed: chromium:1234931
Change-Id: I8f2b603a914fccaeaeb3dcffa63070cf8fb6f0e3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3064604
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76033}
A JSFunction object may count as 'ObjectMayBeUninitialized', yet still
be safe to read for other reasons (e.g. because it has been loaded
through a chain of acquire-loads and immutable-after-initialization
guarantees).
Bug: chromium:1235071,v8:7790
Change-Id: I18c81695f001fd67e69d98dde641b71ed7b7e53d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3064606
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76031}
Change-Id: I0ba9c4bf13ff13e69d960fba44f93124be5a31a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3063499
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76029}
The original CL was flaky because deserialization did not wait correctly
for the compilation of missing functions to finish. The baseline-finished
event was set even when there were still some functions missing. The
combination of deserialization and lazy compilation was also not handled
correctly.
Original change's description:
> [wasm] Support partial serialization of modules
>
> At the moment a WebAssembly module can be serialized successfully when
> all functions were compiled with TurboFan. However, for some functions
> it may not be necessary to be compiled with TurboFan, e.g. for functions
> where Liftoff code is as good as TurboFan code.
>
> With this CL we allow WebAssembly modules to get serialized even when
> not all functions are compiled with TurboFan. Missing functions are
> marked as missing in the serlialization. Upon deserialization, missing
> functions either get compiled by Liftoff, or initialized with a
> lazy-compilation stub, depending on the V8 configuration.
>
> Bug: v8:11862
Change-Id: I79a9e8e14199cff87fce6ae41a87087e047bbc65
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060485
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76017}
Rename CopyAndConvertArrayToCppBuffer as
TryCopyAndConvertArrayToCppBuffer and implement type specialization for
int32_t and double in order to speed up V8 bindings with sequences.
This API is used by Blink code, for example see
https://chromium-review.googlesource.com/c/chromium/src/+/3027405.
Bug: v8:11739
Change-Id: I026a7f5e7833fb1afcc2ea9c296b66c7f733cbb1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3036407
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76016}
Introduce a flush_baseline_code flag to control if baseline code is
flushed or not. Currently flush_baseline_code implies flush_bytecode
as well. So if flush_baseline_code is enabled both bytecode and baseline
code are flushed. If the flag is disabled we only flush bytecode and
not baseline code.
In a follow-up CL we will add support to control baseline and bytecode
flushing independently i.e. we can flush only bytecode / only baseline
code / both.
Bug: v8:11947
Change-Id: I5a90ed38469de64ed1d736d1eaaeabc2985f0783
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059684
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Omer Katz <omerkatz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76003}
This reverts commit bce81d6be0.
Reason for revert: Newly introduced test is flaking, e.g. https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux64%20ASAN/41030/overview or https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux/43171/overview
Original change's description:
> [wasm] Support partial serialization of modules
>
> At the moment a WebAssembly module can be serialized successfully when
> all functions were compiled with TurboFan. However, for some functions
> it may not be necessary to be compiled with TurboFan, e.g. for functions
> where Liftoff code is as good as TurboFan code.
>
> With this CL we allow WebAssembly modules to get serialized even when
> not all functions are compiled with TurboFan. Missing functions are
> marked as missing in the serlialization. Upon deserialization, missing
> functions either get compiled by Liftoff, or initialized with a
> lazy-compilation stub, depending on the V8 configuration.
>
> Bug: v8:11862
> Change-Id: Ic833a17639bf841c5def6fe3c35173fe0376c246
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960209
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75987}
Bug: v8:11862
Change-Id: I5445c097ec47f407e5f951d4cf6d2168113f80e8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3060484
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75997}
The JS API constructor was renamed to "WebAssembly.Tag" to match the
spec:
https://github.com/WebAssembly/exception-handling/issues/159
Rename "exception" to "tag" throughout the codebase for consistency with
the JS API, and to match the spec terminology (e.g. "tag section").
R=clemensb@chromium.org,nicohartmann@chromium.org
Bug: v8:11992
Change-Id: I63f9f3101abfeefd49117461bd59c594ca5dab70
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053583
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75994}
This will change the behavior of %TypedArray%.prototype.fill.
Bug: v8:11111
Change-Id: I66e7d3decf07663a6497c3c86374b3c77ab6a682
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056977
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75988}
At the moment a WebAssembly module can be serialized successfully when
all functions were compiled with TurboFan. However, for some functions
it may not be necessary to be compiled with TurboFan, e.g. for functions
where Liftoff code is as good as TurboFan code.
With this CL we allow WebAssembly modules to get serialized even when
not all functions are compiled with TurboFan. Missing functions are
marked as missing in the serlialization. Upon deserialization, missing
functions either get compiled by Liftoff, or initialized with a
lazy-compilation stub, depending on the V8 configuration.
Bug: v8:11862
Change-Id: Ic833a17639bf841c5def6fe3c35173fe0376c246
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2960209
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75987}
The test makes sure that JSON parsing doesn't stack overflow if given a
deeply nested JSON object. This deep nesting makes the test slow, so we
can test ~the same thing by lowering both the nesting and the stack
size.
Bug: v8:12029
Change-Id: I689ffc1b9db167a1cf1de93beeb09c89e03264a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3059685
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75976}
ComputeMinObjectSlack is called concurrently from background threads
(when --concurrent-inlining) and must therefore be thread-safe.
This CL adds a compiler-specific thread-safe variant
of ComputeMinObjectSlack in addition to the plain old non-thread-safe
one. Thread-safety is achieved through locking: on the bg thread, a
shared lock when traversing transitions, and on the main thread, an
additional exclusive critical section when overwriting prototype
transitions.
Tbr: leszeks@chromium.org
Bug: v8:7790,v8:12010,chromium:1231901
Change-Id: If5af83df1ab896b22477921449fb5ba4c8d3e8a3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3045342
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75949}
It was previously only passed to compilation units in src/bigint/,
but inconsistencies arise when it's not passed to other compilation
units that #include src/bigint/bigint.h.
Fixed: chromium:1233397
Change-Id: Idb310d8c13bad12766699086574aa2c3869eb56c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3056452
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75941}
This reverts commit 67960ba110.
Reason for revert:
This has been properly fixed by https://crrev.com/c/3053740.
Now dcheck_always_on already defaults to false for subprojects
like V8 and no other switch is required. The switch didn't fully
work anyways due to https://crbug.com/1231890.
Original change's description:
> Reland "[build] Add V8-specific dcheck_always_on"
>
> This is a reland of cecc666f4d
>
> Depends on:
> https://crrev.com/c/3043611
>
> Original change's description:
> > [build] Add V8-specific dcheck_always_on
> >
> > This makes the V8 dcheck control independent of Chromium's and
> > prepares switching Chromium's default behavior without affecting V8
> > developers or builders.
> >
> > Preparation for: https://crrev.com/c/2893204
> >
> > Bug: chromium:1225701
> > Change-Id: I520b96019b04196f4420716ff3500ebd6c21666f
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3038528
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#75827}
>
> Bug: chromium:1225701
> Change-Id: I56568b78592addba01793d2d14f768c9ee10103d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041670
> Reviewed-by: Liviu Rau <liviurau@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75839}
Bug: chromium:1225701, chromium:1231890
Change-Id: I7e27f5774d8e162977f30f685da4b15dadcc1084
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3055294
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75935}
The implementation came in with
https://chromium-review.googlesource.com/758999.
This feature was never enabled by default, is not used anywhere, and
is not on any standardization path.
Bug: v8:10953
Change-Id: Ia2b0a556c1fb504a4cd05bdfa9f0a9c5be608d26
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053589
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75934}
In inlined-call-polymorphic we need value numbering phase to
deduce that TurbofanStaticAssert is always true. Turboprop doesn't
enable this phase. So use %OptimizeFunctionTopTier so this function
always tiers up to TurboFan.
Bug: v8:12013
Change-Id: I803bddaca8cb0ba0ad56cbd9874d90b118698e3f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3053579
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75913}
The WebAssembly.Exception constructor creates a WasmExceptionPackage,
which represents an exception thrown from wasm. The first argument is a
WebAssembly.Tag, and the rest are the values to encode in the exception.
R=jkummerow@chromium.org
Bug: v8:11992
Change-Id: I1327b2e4545159397ffe73a061aa577608167b74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049074
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75912}
This is a reland of b99fe75c6d.
The test is now skipped on non-SIMD hardware.
Original change's description:
> [liftoff][arm64] Zero-extend offsets also for SIMD
>
> This extends https://crrev.com/c/2917612 also for SIMD, which
> (sometimes) uses the special {GetMemOpWithImmOffsetZero} method.
> As part of this CL, that method is renamed to {GetEffectiveAddress}
> which IMO is a better name. Also, it just returns a register to make the
> semantic of that function obvious in the signature.
>
> Drive-by: When sign extending to 32 bit, only write to the W portion of
> the register. This is a bit cleaner, and I first thought that
> this would be the bug.
>
> R=jkummerow@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: chromium:1231950, v8:12018
> Change-Id: Ifaefe1f18e3a00534a30c99e3c37ed09d9508f6e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049073
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75898}
TBR=zhin@chromium.orgCC=jkummerow@chromium.org, thibaudm@chromium.org
Bug: chromium:1231950, v8:12018
Change-Id: I662b62fafe99389be7a6c23b970fdf3768f866cf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3051610
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75901}
This reverts commit b99fe75c6d.
Reason for revert:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux/43105
Original change's description:
> [liftoff][arm64] Zero-extend offsets also for SIMD
>
> This extends https://crrev.com/c/2917612 also for SIMD, which
> (sometimes) uses the special {GetMemOpWithImmOffsetZero} method.
> As part of this CL, that method is renamed to {GetEffectiveAddress}
> which IMO is a better name. Also, it just returns a register to make the
> semantic of that function obvious in the signature.
>
> Drive-by: When sign extending to 32 bit, only write to the W portion of
> the register. This is a bit cleaner, and I first thought that
> this would be the bug.
>
> R=jkummerow@chromium.org
> CC=thibaudm@chromium.org
>
> Bug: chromium:1231950, v8:12018
> Change-Id: Ifaefe1f18e3a00534a30c99e3c37ed09d9508f6e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049073
> Reviewed-by: Zhi An Ng <zhin@chromium.org>
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75898}
Bug: chromium:1231950, v8:12018
Change-Id: I4e7a9d6fa6809b7c4d9be919cd5698737d784849
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049085
Auto-Submit: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#75900}
This extends https://crrev.com/c/2917612 also for SIMD, which
(sometimes) uses the special {GetMemOpWithImmOffsetZero} method.
As part of this CL, that method is renamed to {GetEffectiveAddress}
which IMO is a better name. Also, it just returns a register to make the
semantic of that function obvious in the signature.
Drive-by: When sign extending to 32 bit, only write to the W portion of
the register. This is a bit cleaner, and I first thought that
this would be the bug.
R=jkummerow@chromium.org
CC=thibaudm@chromium.org
Bug: chromium:1231950, v8:12018
Change-Id: Ifaefe1f18e3a00534a30c99e3c37ed09d9508f6e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3049073
Reviewed-by: Zhi An Ng <zhin@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75898}
This CL adds support for classes with methods.
More specifically:
- A new ValueSerializer is added and classes are serialized separetely
from functions, although the common parts are handled in the same way
and abstracted away.
- The function prototype is serialized as an object and any missing
information is set up again during deserialization.
- FunctionFlagsToFunctionKinds() is updated to allow for more function
kinds.
- Context serialization is updated to support serializing BlockContexts
and creating ScopeInfos of type CLASS_SCOPE.
- Map serialization is updated to support properties with custom
attributes.
Bug: v8:11525, v8:11706
Change-Id: I16ca7cbc17b1811721081cda05124ce36073f9be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3006416
Commit-Queue: Vicky Kontoura <vkont@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75893}
Enabling --turbo-optimize-apply breaks tests because we are
passing the wrong receiver;
in JSCallReducer::ReduceCallOrConstructWithArrayLikeOrSpread
we create a Call node with the wrong ConvertReceiverMode, we
pass kNullOrUndefined while it should be kAny. This may break
calls to API or in general calls to functions that use the
receiver.
Bug: chromium:1231108, v8:9974
Change-Id: Ib35a1bf8746ad254b6d63274f3ae11b12aa83de8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043690
Commit-Queue: Paolo Severini <paolosev@microsoft.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75886}
This is a reland of 84d5b027a7
It removes support for 8-byte types which were causing
unaligned reads.
Original change's description:
> [fastcall] Implement support for TypedArray arguments
>
> This CL adds TypedArrays as supported arguments for fast API calls.
> It implements "exact type" matching, i.e. if Float32Array is expected
> and e.g. Int32Array is passed instead, the generated code bails to the
> slow callback.
>
> Bug: chromium:1052746, chromium:1018624
> Change-Id: I01d4e681d2b367cbb57b06effcb591c090a23295
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999094
> Commit-Queue: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#75756}
Bug: chromium:1052746, chromium:1018624
Change-Id: I872716d95bde8c340cf04990a3e4ae8ec8cd74a2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3035090
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75877}
According to the spec https://tc39.github.io/proposal-error-cause,
the property 'cause' should not present on Error.prototype.
Bug: v8:12006
Change-Id: Ib1601769793b808c5f5a7065effcc77d1def4cbb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3037911
Reviewed-by: Shu-yu Guo <syg@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75872}
The test is flaky on that hardware but seems to work just fine on other
arm hardware.
R=machenbach@chromium.org
Bug: v8:10948
Change-Id: Ic60cc23c1b4825623a91e3defcd21eada74554a4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043954
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75867}
And use it to remove the set of TurboProp test skips.
BUG=v8:9684,v8:12013
Change-Id: I878e2b9c595449c954735290959d3b38eead5a5b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043963
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75865}
...while on-heap objects are referring to it. This is accomplished
by storing a reference to its associated WasmInstanceObject on every
WasmTypeInfo object.
Details: https://bit.ly/2UxD4hW
Fixed: v8:11953
Change-Id: Ifb6f976142356021393d41c50717d210d525d521
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043959
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Manos Koukoutos <manoskouk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75863}
Some skips are no longer required.
BUG=v8:9684
Change-Id: I921f2032ea5c19429c735120ba80a09b8f1e352e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3043961
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75854}
Adds incompatibility between future/turboprop variants and stress-concurrent-inlining
due to incompatibility from both configs weakly setting --interrupt-budget. Also ensures
we maintain this incompatibility if --future is passed as an extra flag as is done on
some bots.
BUG=v8:9684
Change-Id: I4855b92a64db00da15efc2384e241d4bf0c373c2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3041677
Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75853}
RegExp match indices have shipped since M90
Bug: v8:9548
Change-Id: I8bf54ce1a50b5079aad71140f75c979a09aae5bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3042842
Auto-Submit: Shu-yu Guo <syg@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75848}
