There are only very few custom compiled IC handlers left that go in there, and for each compiled handler we only have 1 cache hit on top25; maximally saving 60ms over 33s. Additionally we'll migrate the remaining handlers to data-driven handlers anyway. Let's try to remove this code.
Bug:
Change-Id: Ib874cc498015046a3ff67c83ea8b10b3c4eb7d0f
Reviewed-on: https://chromium-review.googlesource.com/668409
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48201}
ZoneList still used List as a base class, so this CL merges the two
classes together. We also remove unused functions in List and ZoneList.
We keep the inline header but move it to src/zone/zone-list-inl.h. The
includes that use this header are still quite tangled, but we can fix
that later.
Bug: v8:6333
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ia809813834b2328ff616623f8a843812a1eb42a7
Reviewed-on: https://chromium-review.googlesource.com/681658
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48200}
This is a reland of 9d3c4b4b91
Original change's description:
> [turbofan] Implement lowering of {JSCreateClosure}.
>
> This adds support for inline allocation of {JSFunction} objects as part
> of closures instantiation for {JSCreateClosure} nodes. The lowering is
> limited to instantiation sites which have already seen more than one
> previous instantiation, this avoids the need to increment the respective
> counter.
>
> R=jarin@chromium.org
>
> Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
> Reviewed-on: https://chromium-review.googlesource.com/594287
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48176}
Change-Id: I3ec3880bea89798a34a3878e6122b95db1014151
Reviewed-on: https://chromium-review.googlesource.com/686834
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48198}
The members of HandleScopeImplementer are copied with memcpy when
the isolate is transferred to another thread. List contained some
primitives which allowed us to manually free the backing store, which
was needed in order to ensure that threads would not hold on to
old pointers and use them later. With std::vector, we can't do that.
Here we change the HandleScopeImplementer to instead use a custom
structure DetachableVector, which contains a std::vector but allows
manual detaching and freeing of the backing store. This allows us to
maintain the old behavior.
Bug: v8:6333
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0
Reviewed-on: https://chromium-review.googlesource.com/660125
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48197}
We used to only mark top-level SFIs with the 'deserialized' bit.
Now we do it for every SFI that has cached code. This is the
first step to surface caching information in the future.
R=cbruni@chromium.org
Bug: chromium:769166
Change-Id: I12f21511419ce54fd07a2cc277a65866660c366a
Reviewed-on: https://chromium-review.googlesource.com/686715
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48184}
There was an issue with passing float32 parameters, if the value was
spilled on the stack and passed as stack parameter.
First, we sometimes reduced the stack pointer by 8 bytes instead of 4,
and second, there was a mismatch between movsd and movss.
R=titzer@chromium.org
Bug: chromium:718858
Change-Id: Ia884df369ddd95adeff3733f9715f589996f0b65
Also-By: ahaas@chromium.org
Reviewed-on: https://chromium-review.googlesource.com/684738
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48181}
This reverts commit 9d3c4b4b91.
Reason for revert: Breaks cctest/test-debug/NoBreakWhenBootstrapping in no-snap mode.
Original change's description:
> [turbofan] Implement lowering of {JSCreateClosure}.
>
> This adds support for inline allocation of {JSFunction} objects as part
> of closures instantiation for {JSCreateClosure} nodes. The lowering is
> limited to instantiation sites which have already seen more than one
> previous instantiation, this avoids the need to increment the respective
> counter.
>
> R=jarin@chromium.org
>
> Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
> Reviewed-on: https://chromium-review.googlesource.com/594287
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48176}
TBR=mstarzinger@chromium.org,jarin@chromium.org
Change-Id: Id52281f6a3c0b7c2603053ecf002777d5b0d6f1f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/686534
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48178}
This adds support for inline allocation of {JSFunction} objects as part
of closures instantiation for {JSCreateClosure} nodes. The lowering is
limited to instantiation sites which have already seen more than one
previous instantiation, this avoids the need to increment the respective
counter.
R=jarin@chromium.org
Change-Id: I462c557453fe58bc5f09020a3d5ebdf11c2ea68b
Reviewed-on: https://chromium-review.googlesource.com/594287
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48176}
- Move things to conversions.cc that don't need to be in headers
- Turn InternalStringToInt into a subclassable helper class
so we can re-use it for BigInt.parseInt
- Bonus: play a round of IWYU with all the .cc files who thought that
#including conversions-inl.h would give them nice Unicode things
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I64022543a9b83002e2b78416c7e87b40a1a016e6
Reviewed-on: https://chromium-review.googlesource.com/673725
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48174}
This CL teaches the respective bytecode handlers and standalone stubs
about BigInts, and collects "kBigInt" feedback for them. However,
Turbofan does not yet care about such feedback, so it is simply converted
to "any" for now (making TF emit stub calls for BigInt operations).
Bug: v8:6791
Change-Id: I6440c108ccd79058d77adc2a6041251db9d5f81d
Reviewed-on: https://chromium-review.googlesource.com/683758
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48173}
This fixes the signature of "Math.abs" from "(signed) -> signed" to
"(signed) -> unsigned" and hence fixes cases where the absolute value
would overflow the range of signed 32-bit values. This is in sync with
spec erratas (and ECMAScript semantics).
Note that this also switches the underlying implementation of the above
absolute value function to a branch-free version.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-3
BUG=v8:6838
Change-Id: Ib13b7ecd336ae386cbde7c574e727bf52f841e00
Reviewed-on: https://chromium-review.googlesource.com/684181
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48169}
Follow up to https://chromium-review.googlesource.com/671020
We still didn't return the correct amount of invalid characters, according to
the Encoding spec ( https://encoding.spec.whatwg.org/#utf-8-decoder ), when we
saw a byte sequence which was as start of an overlong / invalid sequence, but
there weren't enough continuation bytes.
A more rigorous test will follow in
https://chromium-review.googlesource.com/c/v8/v8/+/681217
BUG=chromium:765608
Change-Id: I535670edc14d3bae144e5a9ca373f12eec78a934
Reviewed-on: https://chromium-review.googlesource.com/681674
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48165}
This is a reland of 629406d1e9
Original change's description:
> [snapshot] include version string in the startup snapshot.
>
> This is to easier diagnose build issues involving the snapshot.
> Sample error message for mismatching snapshot:
>
> #
> # Fatal error in ../../src/snapshot/snapshot-common.cc, line 286
> # Version mismatch between V8 binary and snapshot.
> # V8 binary version: 6.3.1 (candidate)
> # Snapshot version: 6.3.0 (candidate)
> # The snapshot consists of 2820444 bytes and contains 1 contexts.
> #
>
>
> R=machenbach@chromium.org
>
> Bug: chromium:764327
> Change-Id: Icdc7aeac77819b113985b424feda814a072d5406
> Reviewed-on: https://chromium-review.googlesource.com/684295
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48161}
Bug: chromium:764327
Change-Id: I3721689824e0a6909eede86d0829dc258ae40c4d
Reviewed-on: https://chromium-review.googlesource.com/684494
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48164}
- Add kProduceExhaustiveCodeCache to v8::ScriptCompiler::CompileOptions
to request eager compilation to add as much as possible to the code
cache for the script.
- Repurpose ParseInfo::kLazy flag.
- Remove ParseInfo::kDebug flag.
- Remove --serialize-toplevel as it has become obsolete.
R=marja@chromium.org
Bug: chromium:768705
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ife14f7a1d1c02e525f0b9dbfd2452013d67c7167
Reviewed-on: https://chromium-review.googlesource.com/684019
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48160}
In the test-run-wasm and test-run-wasm-64 cctests it is not possible to
call runtime functions. To test traps in these cctests we therefore
replace the runtime call with a call to a c-callback, followed by a
return. This CL fixes the problem that the return did not clean up stack
parameters.
This CL unblocks
https://chromium-review.googlesource.com/c/v8/v8/+/671008. Originally I
wanted to mitigate the problem in that CL by defining an additional
parameter register for arm. However, adding additional parameter
registers lets other tests fail.
R=titzer@chromium.org, rodolph.perfetta@arm.comCC=enricobacis@google.com
Bug: v8:6858
Change-Id: Ia8de73b70a0677ca4d379ed5b16272faee92a78d
Reviewed-on: https://chromium-review.googlesource.com/684017
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48158}
This caused trouble for my downstream CI tests, even though it builds
successfully in the canonical v8 tree. To be investigated properly
later.
Bug: chromium:746958
Change-Id: I180a5ecc51051e4eb6617180ccba787ff80bcf45
Reviewed-on: https://chromium-review.googlesource.com/682695
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48151}
This is a second attempt at landing CL 644866 which was reverted by
CL 667019.
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
A JS typed (uint_16) array is used to hold the thrown values. This
allows all WASM types to be stored (i32, i64, f32, and f64) as well as
be inspected in JS.
The previous CL was reverted because the WASM compiler made calls to
run time functions with tagged objects, which must not be done. To fix
this, all run time calls use the thread-level isolate to hold the
exception being processed.
Bug: v8:6577
Change-Id: I4b1ef7e2847b71a2fab8e9934a0531057db9de63
Reviewed-on: https://chromium-review.googlesource.com/677056
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48148}
There is no jumbo_executable target atm, so split the cctest v8_executable
target into cctest and cctest_sources.
Bug: chromium:746958
Change-Id: Iec0956234d026039c4d29921170dd2f0955222ca
Reviewed-on: https://chromium-review.googlesource.com/680575
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48147}
Previously, we would blindly register new handler data, leading to us leaking
the old handler data. This meant we could then end up with overlapping handler
data where the instruction offset and landing pads didn't line up right.
Bug: v8:6841
Change-Id: Iedcd75925b8d9d59c8f9accf288cae954fdc568f
Reviewed-on: https://chromium-review.googlesource.com/677632
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48144}
This fixes the signatures of "Math.ceil", "Math.floor" and "Math.sqrt"
from "(float?) -> float" to "(float?) -> floatish" which avoids using a
resulting float value without coercing the value via explicit "fround"
annotations. This ensures proper ECMAScript semantics are maintained.
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-2
BUG=v8:6838
Change-Id: Ib5821641265bc862184adb270e8dbf8c703fdfb0
Reviewed-on: https://chromium-review.googlesource.com/681694
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48142}
This is a reland of ec952aaa68.
Included is a fix that ensures that top_on_previous_step_ is cleared when we
release a page.
Original change's description:
> Reland "[profiler] proper observation of old space inline allocations"
>
> This is a reland of 672a41c3ca
> Original change's description:
> > [profiler] proper observation of old space inline allocations
> >
> > Bug: chromium:633920
> > Change-Id: I9a2f4a89f6b9c0f63cb3b166b06a88a12f0a203c
> > Reviewed-on: https://chromium-review.googlesource.com/631696
> > Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48043}
>
> Bug: chromium:633920
> Change-Id: I6fe743d31b8ff26f3858488d4c014c62d3c85add
> Reviewed-on: https://chromium-review.googlesource.com/671127
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
> Cr-Commit-Position: refs/heads/master@{#48085}
Bug: chromium:633920
Change-Id: I8a0dcc4eaffc1f1d3ac5b3f8d344001cdae36606
Reviewed-on: https://chromium-review.googlesource.com/677407
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#48141}
When inlining based on SharedFunctionInfo rather than based on concrete
JSFunction, we weren't able to properly optimize array, object and
regexp literals inside the inlinee, because we didn't know the concrete
FeedbackVector for the inlinee inside JSCreateLowering. This was because
JSCreateLowering wasn't properly updated after the literals moved to the
FeedbackVector. Now with this CL we also have the VectorSlotPair on the
literal creation operators, just like we do for property accesses and
calls, and are thus able to always access the appropriate FeedbackVector
and optimize the literal creation.
The impact is illustrated by the micro-benchmark on the tracking bug,
which goes from
createEmptyArrayLiteral: 1846 ms.
createShallowArrayLiteral: 1868 ms.
createShallowObjectLiteral: 2246 ms.
to
createEmptyArrayLiteral: 1175 ms.
createShallowArrayLiteral: 1187 ms.
createShallowObjectLiteral: 1195 ms.
with this CL, so up to 2x faster now.
Drive-by-fix: Also remove the unused CreateEmptyObjectLiteral builtin
and cleanup the names of the other builtins to be consistent with the
names of the TurboFan operators and Ignition bytecodes.
Bug: v8:6856
Change-Id: I453828d019b27c9aa1344edac0dd84e91a457097
Reviewed-on: https://chromium-review.googlesource.com/680656
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48140}
This fixes the signature of "Math.min" and "Math.max" for integer values
from "(int, int...) -> signed" to "(signed, signed..) -> signed" which
properly distinguishes signed from unsigned values now. This is in sync
with the spec errata (and ECMAScript semantics).
R=clemensh@chromium.org
TEST=mjsunit/regress/regress-6838-1
BUG=v8:6838
Change-Id: Id72836513dd86e93472a22cf1ac2e2d382ed4f23
Reviewed-on: https://chromium-review.googlesource.com/681357
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48139}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=yangguo@chromium.org
Bug: v8:6837
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I88e5afea1ad0fdf23a81b380e64ff356bbc20112
Reviewed-on: https://chromium-review.googlesource.com/681374
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48138}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=ulan@chromium.org
Bug: v8:6837
Change-Id: I8d900f3c703dea6ee3bcc225a1d2754e91666b9d
Reviewed-on: https://chromium-review.googlesource.com/671047
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48136}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=jarin@chromium.org
Bug: v8:6837
Change-Id: I712580c2a4326e06ee3d6d0eb4ff8c7d24f5fdb9
Reviewed-on: https://chromium-review.googlesource.com/671227
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48135}
Track whether the async arrow func parameter list was simple or not; the
information is already there, we just didn't pipe it through correctly. It's
needed by PreParser so that it can create the correct Scope structure.
Implementation notes:
- I could've used async_classifier for transmitting the "is_simple" bit, but I
made it explicit (it would be unnecessary to use ExpressionClassifier for
this, as we're not classifying any expressions) instead.
- I'm also moving work (setting parameter_list.is_simple) from Parser to
ParserBase, and adding a DCHECK in Parser to assert that the work was indeed
already done.
BUG=v8:5516,chromium:765532
Change-Id: Iacf91b150d1b57996544b5e64baa7d91ac134445
Reviewed-on: https://chromium-review.googlesource.com/674695
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48132}
Tagged templates were previously desugared during parsing using some
combination of runtime support written in JavaScript and C++, which
prevented some optimizations from happening, namely the constant folding
of the template object in TurboFan optimized code. This CL adds a new
bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
node), which represents the abstract operation in the ES6 specification
and allows TurboFan to simply constant-fold template objects at compile
time (which is explicitly supported by the specification).
This also pays down some technical debt by removing the template.js
runtime support and therefore should reduce the size of the native
context (snapshot) a bit.
With this change in-place the ES6 version microbenchmark in the
referenced tracking bug is now faster than the transpiled Babel
code, it goes from
templateStringTagES5: 4552 ms.
templateStringTagES6: 14185 ms.
templateStringTagBabel: 7626 ms.
to
templateStringTagES5: 4515 ms.
templateStringTagES6: 7491 ms.
templateStringTagBabel: 7639 ms.
which corresponds to a solid 45% reduction in execution time. With some
further optimizations the ES6 version should be able to outperform the
ES5 version. This micro-benchmark should be fairly representative of the
six-speed-templatestringtag-es6 benchmark, and as such that benchmark
should also improve by around 50%.
Bug: v8:6819,v8:6820
Tbr: mlippautz@chromium.org
Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
Reviewed-on: https://chromium-review.googlesource.com/677462
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48126}
- Moves GetRandomMmapAddr from platform to v8::internal allocation
primitives, in preparation for delegating this to the embedder.
- Adds hint parameters to OS functions that used to use this function.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iad72e6eac9c08a3e22c2cd2b2905623b8e514ae0
Reviewed-on: https://chromium-review.googlesource.com/677777
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48124}
TurboAssembler::CallRecordWriteStub contains info that could be used to
conditionally skip generational write barrier or skip saving float-point
registers. This commits uses those info in RecordWrite stub.
Bug: chromium:749486
Change-Id: I41c9a593473e1f8863a09887fd2ce917f1d4fb3b
Reviewed-on: https://chromium-review.googlesource.com/672527
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48123}
This change enables moving the WasmToJSWrapper off the GCed heap
R=bradnelson@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
Bug:
Change-Id: I1ea8810fa7b71bcb2a80a1390742db64872c5bb1
Reviewed-on: https://chromium-review.googlesource.com/665977
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48118}
This is a reland of c6b153fd69
Original change's description:
> [cctest] Add fuzz tests for generating parallel moves.
>
> These new tests are somewhat similar to the existing gap resolver tests except
> we use the code generator and eventually run the generated code. The main idea
> is to cover cases that are difficult to hit, such as move from/to slots which
> are out of range of loads and stores, but may happen nonetheless.
>
> At this time, the tests only make sure the code generator actually generated
> some code, and that this code runs. In the future, it would be great to also
> check that the moves were actually performed.
>
> Bug: v8:6553
> Change-Id: I089a25fa05b3a20649658bb8952926ab11f91d68
> Reviewed-on: https://chromium-review.googlesource.com/574850
> Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47733}
Bug: v8:6553
Change-Id: Ia3eac9d7e6a23e2f6fea839b71d460cb7ad6ff6e
Reviewed-on: https://chromium-review.googlesource.com/645868
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#48115}
This is a reland of f2cd10db14
Original change's description:
> Reland "[Memory] Move VirtualMemory out of base:: platform."
>
> This is a reland of 4dd293d922
> Original change's description:
> > [Memory] Move VirtualMemory out of base:: platform.
> >
> > - Moves base::VirtualMemory to v8::internal::VirtualMemory.
> > - Makes VirtualMemory platform-independent by moving internals to new
> > OS:: static methods, for each platform.
> >
> > This will make it easier to delegate memory management in VirtualMemory
> > to V8::Platform, so that embedders like Blink can override it. We can't
> > depend on V8::Platform in base/platform.
> >
> > Bug: chromium:756050
> > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> > Change-Id: Iadfe230b6850bd917727a373f277afded9883adf
> > Reviewed-on: https://chromium-review.googlesource.com/653214
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48048}
>
> Bug: chromium:756050
> Change-Id: Ib492c7c69f1833be127a571808301e96b84b8aa2
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/671125
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48084}
Bug: chromium:756050
Change-Id: Ie596730b5cefc38137cab7fc1f76613f5af7b825
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/675283
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48113}
In the current implementation, compilation would fail because
operator<< is not defined for enum classes. For others, the compiler
finds more than one operator<<, so it fails because it's ambiguous.
This CL fixes this by printing the integer value for enums, uses the
operator<< for all values that support it, and prints "<unprintable>"
otherwise.
Also, lots of unit tests.
R=ishell@chromium.org
Bug: v8:6837
Change-Id: I895ed226672aa07213f9605e094b87af186ec2e4
Reviewed-on: https://chromium-review.googlesource.com/671016
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48110}
And add some tests for (seemingly) previously uncovered cases.
The additional check for unreachable code is not needed any more, since
polymorphic stack values get assigned a specific type on their first
use or validation anyway. Hence the first entry in the br_table will
assign specific types to all polymorphic stack values, and type checking
will fail if later entries do not match.
R=rossberg@chromium.orgCC=titzer@chromium.org
Change-Id: I1d0f91f927a2aa5186f874112e91ebffa1f1b3a7
Reviewed-on: https://chromium-review.googlesource.com/675405
Reviewed-by: Andreas Rossberg <rossberg@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48109}
This fix is two-fold:
1) Incremental UTF-8 decoding: Unify incorrect UTF-8 handling between V8 and
Blink.
Incremental UTF-8 decoding used to allow some overlong sequences / invalid code
points which Blink treated as errors. This caused the decoder and the Blink
UTF-8 decoder to produce a different number of bytes, resulting in random
failures when scripts were streamed (especially, this was detected by the
skipping inner functions feature which adds CHECKs against expected function
positions).
2) Non-incremental UTF-8 decoding: return the correct amount of invalid characters.
According to the encoding spec ( https://encoding.spec.whatwg.org/#utf-8-decoder
), the first byte of an overlong sequence / invalid code point generates an
invalid character, and the rest of the bytes are not processed (i.e., pushed
back to the byte stream). When they're handled, they will look like lonely
continuation bytes, and will generate an invalid character each.
As a result, an overlong 4-byte sequence should generate 4 invalid characters
(not 1).
This is a potentially breaking change, since the (non-incremental) UTF-8
decoding is exposed via the API (String::NewFromUtf8). The behavioral difference
happens when the client is passing in invalid UTF-8 (containing overlong /
surrogate sequences).
However, afaict, this doesn't change the semantics of any JavaScript program:
according to the ECMAScript spec, the program is a sequence of Unicode code
points, and there's no way to invoke the UTF-8 decoding functionalities from
inside JavaScript. Though, this changes the behavior of d8 when decoding source
files which are invalid UTF-8.
This doesn't change anything related to URI decoding (it already throws
exceptions for overlong sequences / invalid code points).
BUG: chromium:765608, chromium:758236, v8:5516
Bug:
Change-Id: Ib029f6a8e87186794b092e4e8af32d01cee3ada0
Reviewed-on: https://chromium-review.googlesource.com/671020
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48105}
By adding a per test source file namespace, we can avoid a lot of
symbol collisions in jumbo builds.
While we're at it, let's remove some "using" statements that also
cause trouble.
Bug: chromium:746958
Change-Id: I6f8a723e1ba5905888638e0687b23193f3f012ca
Reviewed-on: https://chromium-review.googlesource.com/676803
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Cr-Commit-Position: refs/heads/master@{#48102}
Memory instantiate on initialize should always patch memory
references. If memory references are not patched for no initial
memory, on subsequent calls to grow_memory in wasm functions for
instances that share a module, the references will be patched
without resetting cloned compiled values to their correct initial
values.
BUG=chromium:763439
Change-Id: I666439332379b02aa344e99d61ef3dc88ab86cc8
Reviewed-on: https://chromium-review.googlesource.com/674707
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48097}
Along with BigInt.prototype. Their functions only have skeleton
implementations. The purpose of this change is to make it easier
to gradually increase test coverage (e.g. for toString(radix)).
Of course this is still behind the --harmony-bigint flag.
Bug: v8:6791
Change-Id: Ic307fd9165c56ac782fba18d648ce893daaa718f
Reviewed-on: https://chromium-review.googlesource.com/671209
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48094}
There is no support to emulate atomic WASM operations on big-endian
platforms, since this would require bit swapping as a part of atomic
operations. Therefore, cctest/test-run-wasm-atomics/* will be skipped.
TEST=cctest/test-run-wasm-atomics/*
BUG=
Change-Id: I1a8b085f816f615011788092e6fc8a8390678382
Reviewed-on: https://chromium-review.googlesource.com/671010
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@imgtec.com>
Cr-Commit-Position: refs/heads/master@{#48093}
This fixes a few leftovers where we use WASM_EXEC_TEST, but then
unconditionally execute the compiled code, and also changes more tests
to use WASM_EXEC_TEST, hence run in both the interpreter and compiled
code.
Once we have land the baseline compiler, those tests will also execute
in baseline compilation mode.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I79598df21a7538934306e01ca6593f05afe19ed3
Reviewed-on: https://chromium-review.googlesource.com/672528
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48091}
This reverts commit f2cd10db14.
Reason for revert: Blocks the roll https://chromium-review.googlesource.com/c/chromium/src/+/674623
Original change's description:
> Reland "[Memory] Move VirtualMemory out of base:: platform."
>
> This is a reland of 4dd293d922
> Original change's description:
> > [Memory] Move VirtualMemory out of base:: platform.
> >
> > - Moves base::VirtualMemory to v8::internal::VirtualMemory.
> > - Makes VirtualMemory platform-independent by moving internals to new
> > OS:: static methods, for each platform.
> >
> > This will make it easier to delegate memory management in VirtualMemory
> > to V8::Platform, so that embedders like Blink can override it. We can't
> > depend on V8::Platform in base/platform.
> >
> > Bug: chromium:756050
> > Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> > Change-Id: Iadfe230b6850bd917727a373f277afded9883adf
> > Reviewed-on: https://chromium-review.googlesource.com/653214
> > Commit-Queue: Bill Budge <bbudge@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48048}
>
> Bug: chromium:756050
> Change-Id: Ib492c7c69f1833be127a571808301e96b84b8aa2
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/671125
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48084}
TBR=bbudge@chromium.org,ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org,scottmg@chromium.org
Change-Id: I04176d77ca9ad8315b0e1bb2b21f40f2c8ab9536
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/674843
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48088}
This is a reland of 4dd293d922
Original change's description:
> [Memory] Move VirtualMemory out of base:: platform.
>
> - Moves base::VirtualMemory to v8::internal::VirtualMemory.
> - Makes VirtualMemory platform-independent by moving internals to new
> OS:: static methods, for each platform.
>
> This will make it easier to delegate memory management in VirtualMemory
> to V8::Platform, so that embedders like Blink can override it. We can't
> depend on V8::Platform in base/platform.
>
> Bug: chromium:756050
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Iadfe230b6850bd917727a373f277afded9883adf
> Reviewed-on: https://chromium-review.googlesource.com/653214
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48048}
Bug: chromium:756050
Change-Id: Ib492c7c69f1833be127a571808301e96b84b8aa2
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/671125
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48084}
Use the (D)CHECK_{EQ,NE,GT,...} macros instead of (D)CHECK with an
embedded comparison. This gives better error messages and also does the
right comparison for signed/unsigned mismatches.
This will allow us to reenable the readability/check cpplint check.
R=ahaas@chromium.org
Bug: v8:6837
Change-Id: Ic8966dfeacf02b2684eeef23fde99ec2be4ed81e
Reviewed-on: https://chromium-review.googlesource.com/671364
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48080}
Removes
- SequentialMarkingDeque
- The ability to handle marking deque overflow
- BlackToGrey transitions
We switched to a different marking work list on M61 that fails
in OOM upon failing to allocate Segments used in the work list.
Bug: chromium:758570
Change-Id: I66e2ab912271bf84b085dccc9b4bdd96076b64fb
Reviewed-on: https://chromium-review.googlesource.com/632676
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48078}
This is primarily to aid in testing the Wasm out of bounds trap handler. We
keep track of how many faults have been recovered by the Wasm trap handler. This
count is exposed to JavaScript through a testing-only runtime function. This
allows tests to verify whether the trap handler is actually running.
Bug: v8:5277
Change-Id: Ie8037a36d84eb08166c6e40c7225d912683d5786
Reviewed-on: https://chromium-review.googlesource.com/665968
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48076}
The bug occurred when we detected an erroneous char late, and put the last
character in a chunk into the "incomplete char" buffer. It was not correctly
retrieved when seeking.
BUG=v8:6836
Change-Id: I8ca946dfdb39244c5ca0bdcebe047047010b3a07
Reviewed-on: https://chromium-review.googlesource.com/670729
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48066}
This reverts commit 4dd293d922.
Reason for revert: Blocks roll: https://chromium-review.googlesource.com/c/chromium/src/+/669785
Original change's description:
> [Memory] Move VirtualMemory out of base:: platform.
>
> - Moves base::VirtualMemory to v8::internal::VirtualMemory.
> - Makes VirtualMemory platform-independent by moving internals to new
> OS:: static methods, for each platform.
>
> This will make it easier to delegate memory management in VirtualMemory
> to V8::Platform, so that embedders like Blink can override it. We can't
> depend on V8::Platform in base/platform.
>
> Bug: chromium:756050
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Iadfe230b6850bd917727a373f277afded9883adf
> Reviewed-on: https://chromium-review.googlesource.com/653214
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48048}
TBR=bbudge@chromium.org,ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org,scottmg@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:756050
Change-Id: Ice2618ef72950e1b64c31434a239c626aa5e5970
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/670843
Reviewed-by: Michael Hablich <hablich@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48062}
When using Lockers and Unlockers it is possible to create a
scenario where multiple threads point to the same optimized
code object. When that happens, if one of the threads triggers
deoptimization, then the stack replacement needs to happen in
the stacks of all threads.
With this CL, the deoptimizer visits all threads to do so.
The CL also adds three tests where V8 used to crash due to this
issue.
Bug: v8:6563
Change-Id: I74e9af472d4833aa8d13e579df45133791f6a503
Reviewed-on: https://chromium-review.googlesource.com/670783
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#48060}
This reverts commit ee5c31f335.
Reason for revert: Fixed compiler failure
Original change's description:
> Revert "[wasm] A simple allocator datastructure for off-the heap"
>
> This reverts commit 110d9ab005.
>
> Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
>
> Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
>
> Original change's description:
> > [wasm] A simple allocator datastructure for off-the heap
> >
> > We'll use this allocator in a follow-up CL to:
> > - allocate speculative sizes of memory for a module that's being
> > compiled (e.g. 2*size of wasm code).
> > - each module will own such a sub-pool, and then use it to allocate
> > contiguous chunks of memory for code.
> >
> > The underlying assumptions for the chosen allocation strategy is that:
> > - the allocation granularity for pools is 1 page, so that no one page
> > is owned by more than one wasm module
> > - typical pool sizes (given module sizes) are multiple pages.
> > - modules and module instances are typically few and long lived. Typically,
> > we expect one module and one instance.
> >
> > This means we shouldn't expect fragmentations that lead to code being
> > non-allocatable, or prohibitively many ranges.
> >
> > The data structure just manages ranges of addresses. Virtual memory management
> > will be separate, as part of the responsibility of a "WasmHeap"
> > that will be introduced in the future. So will concurrency control.
> >
> > Bug:
> > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> > Reviewed-on: https://chromium-review.googlesource.com/669296
> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Eric Holk <eholk@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48053}
>
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
>
> Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/670141
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48054}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670142
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48055}
This reverts commit 110d9ab005.
Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
Original change's description:
> [wasm] A simple allocator datastructure for off-the heap
>
> We'll use this allocator in a follow-up CL to:
> - allocate speculative sizes of memory for a module that's being
> compiled (e.g. 2*size of wasm code).
> - each module will own such a sub-pool, and then use it to allocate
> contiguous chunks of memory for code.
>
> The underlying assumptions for the chosen allocation strategy is that:
> - the allocation granularity for pools is 1 page, so that no one page
> is owned by more than one wasm module
> - typical pool sizes (given module sizes) are multiple pages.
> - modules and module instances are typically few and long lived. Typically,
> we expect one module and one instance.
>
> This means we shouldn't expect fragmentations that lead to code being
> non-allocatable, or prohibitively many ranges.
>
> The data structure just manages ranges of addresses. Virtual memory management
> will be separate, as part of the responsibility of a "WasmHeap"
> that will be introduced in the future. So will concurrency control.
>
> Bug:
> Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> Reviewed-on: https://chromium-review.googlesource.com/669296
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48053}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670141
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48054}
We'll use this allocator in a follow-up CL to:
- allocate speculative sizes of memory for a module that's being
compiled (e.g. 2*size of wasm code).
- each module will own such a sub-pool, and then use it to allocate
contiguous chunks of memory for code.
The underlying assumptions for the chosen allocation strategy is that:
- the allocation granularity for pools is 1 page, so that no one page
is owned by more than one wasm module
- typical pool sizes (given module sizes) are multiple pages.
- modules and module instances are typically few and long lived. Typically,
we expect one module and one instance.
This means we shouldn't expect fragmentations that lead to code being
non-allocatable, or prohibitively many ranges.
The data structure just manages ranges of addresses. Virtual memory management
will be separate, as part of the responsibility of a "WasmHeap"
that will be introduced in the future. So will concurrency control.
Bug:
Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
Reviewed-on: https://chromium-review.googlesource.com/669296
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48053}
This reverts commit 7b5a40222e.
Reason for revert: GC stress-test failures exposed by 7742e534a8https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/15110/steps/Mjsunit/logs/exceptions
Original change's description:
> Add capability of throwing values in WASM
>
> Extends the current implementation of WASM exceptions to be able to
> throw exceptions with values (not just tags).
>
> An JS typed array (uint_16) is used to hold thrown values, so that the
> thrown values can be inspected in JS.
>
> Bug: v8:6577
> Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
> Reviewed-on: https://chromium-review.googlesource.com/633866
> Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48001}
TBR=bbudge@chromium.org,mtrofin@chromium.org,eholk@chromium.org,clemensh@chromium.org,kschimpf@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6577
Change-Id: I8f545183c2d2abb1bf4a0b3ee23379f3754ffd55
Reviewed-on: https://chromium-review.googlesource.com/667019
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48050}
This reverts commit c87f8954cc.
Reason for revert: LazyDeoptimizationMultithread failing.
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20TSAN%20-%20concurrent%20marking/builds/1876/steps/Bisect%20c87f8954.Retry/logs/LazyDeoptimizationMul..
Original change's description:
> Deoptimization and multithreading.
>
> When using Lockers and Unlockers it is possible to create a
> scenario where multiple threads point to the same optimized
> code object. When that happens, if one of the threads triggers
> deoptimization, then the stack replacement needs to happen in
> the stacks of all threads.
> With this CL, the deoptimizer visits all threads to do so.
> The CL also adds three tests where V8 used to crash.
>
> Bug: v8:6563
> Change-Id: Iea88f47af2f31181c0ef06d898faccde9ad14432
> Reviewed-on: https://chromium-review.googlesource.com/657423
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Cr-Commit-Position: refs/heads/master@{#48033}
TBR=mstarzinger@chromium.org,jarin@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: I290c9e339c367f68c0d1b6f7c0780cdbbbdf3f8a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6563
Reviewed-on: https://chromium-review.googlesource.com/669399
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48049}
- Moves base::VirtualMemory to v8::internal::VirtualMemory.
- Makes VirtualMemory platform-independent by moving internals to new
OS:: static methods, for each platform.
This will make it easier to delegate memory management in VirtualMemory
to V8::Platform, so that embedders like Blink can override it. We can't
depend on V8::Platform in base/platform.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iadfe230b6850bd917727a373f277afded9883adf
Reviewed-on: https://chromium-review.googlesource.com/653214
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48048}
Empty slot set buckets can leak in the following scenarios.
Scenario 1 (large object space):
1) A large array is allocated in the large object space.
2) The array is filled with old->new references, which allocates new
slot set buckets.
3) The references are overwritten with smis or old space pointers, which
make the slots set buckets empty.
4) Garbage collection (scavenge or mark-compact) iterates the slots set
of the array and pre-frees the empty buckets.
5) Steps 2-4 repeated many times and leak arbitary many empty buckets.
The fix to free empty buckets for large object space in mark-compact.
Scenario 2 (no mark-compact):
1) A small array is allocated in the old space.
2) The array is filled with old->new references, which allocates new
slot set buckets.
3) The references are overwritten with smis or old space pointers, which
make the slots set buckets empty.
4) Scavenge iterates the slots set of the array and pre-frees the empty
buckets.
5) Steps 2-4 repeated many times and leak arbitary many empty buckets.
The fix to free empty buckets for swept pages in scavenger.
Bug: v8:6800
TBR: mlippautz@chromium.org
Change-Id: I48d94870f5acf4f6208858271886911c895a9126
Reviewed-on: https://chromium-review.googlesource.com/668442
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48041}
Support inlining of Array.prototype.filter in TurboFan.
Bug: v8:1956
Change-Id: Iba4d683aaa86c6104e8a1cf4d0f549a0c516576a
Reviewed-on: https://chromium-review.googlesource.com/657021
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48040}
Given that the index we use is checked to be in array index range there is no
need for a costly ToString conversion. All involved helpers for lookup up
properties directly support Smi/HeapNumber indices directly.
Cleanup: Rename GotoUnlessNumberLessThan => GotoIfNumberGreaterThanOrEqual
Change-Id: Iaddc4940f5d984572aa218d568ca71bf694cee74
Reviewed-on: https://chromium-review.googlesource.com/640388
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48039}
When using Lockers and Unlockers it is possible to create a
scenario where multiple threads point to the same optimized
code object. When that happens, if one of the threads triggers
deoptimization, then the stack replacement needs to happen in
the stacks of all threads.
With this CL, the deoptimizer visits all threads to do so.
The CL also adds three tests where V8 used to crash.
Bug: v8:6563
Change-Id: Iea88f47af2f31181c0ef06d898faccde9ad14432
Reviewed-on: https://chromium-review.googlesource.com/657423
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#48033}
When accessing the buffer in 1 byte increments, the order should
be reversed for BE.
R=petermarshall@chromium.org, yangguo@chromium.org
BUG=
LOG=N
Change-Id: I27a57e12479d1c00488546a92428b9183d87f8bf
Reviewed-on: https://chromium-review.googlesource.com/667902
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#48031}
This patch ensures a `TypeError` is thrown when the argument passed to
`Array.prototype.sort` or `%TypedArray%.prototype.sort` is neither a
function nor `undefined`.
Every other major JavaScript engine already threw in this case. Making
V8’s behavior match increases interoperability.
https://github.com/tc39/ecma262/pull/785
BUG=v8:6542
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I412a59810abdd118217c8d8361389ec6c2f640bd
Reviewed-on: https://chromium-review.googlesource.com/668356
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48028}
In this CL I implement streaming compilation for WebAssembly,
as described in the design doc I have sent out already.
In this implementation the decoding of sections other than the
code section is done immediately on the foreground thread.
Eventually all decoding should happen in the background. I
think it is acceptable to do the decoding on the foreground
thread for now because I have finished it already, and
decoding in the background would add even more complexity to
this CL.
Bug:v8:6785
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I285e1e5e1a5a243113c92571b25ee9bae551d0ed
Reviewed-on: https://chromium-review.googlesource.com/631721
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48022}
- Validate that atomic ops can only be called when shared memory is declared
- Throw Compile/Link erros on mismatch between declared, imported memory
- Test harness helpers for setting shared memory, tests
BUG=v8:6532
R=binji@chromium.org, bradnelson@chromium.org
Change-Id: I43fe3d04bb7e3e0a2cecca0528578f98844d2608
Reviewed-on: https://chromium-review.googlesource.com/665379
Commit-Queue: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48019}
This patch ensures that an object returned by AllocateRaw is marked
black if black allocation starts during the object allocation.
This fixes the following issue:
1) Generated code requests allocation of size N for folded allocation.
2) Runtime gets a free list node at address A of size N+M and sets up
a linear allocation area with top = A+N and limit = A+N+M.
3) Runtime invokes the allocation observer that starts incremental marking
and start black allocation. The area [A+N, A+N+M) is marked black.
4) Runtime returns a white object at address A as the allocation result.
5) Generated code moves the top pointer to A and does bump pointer
allocations of white objects from A to A+N+M.
6) Object allocated new A+N can have the impossible marbit pattern.
Bug: chromium:694255
Change-Id: I09ceebc97a510fa5fe4ff20706bc46a99f8b7cf4
Reviewed-on: https://chromium-review.googlesource.com/638338
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48005}
Extends the current implementation of WASM exceptions to be able to
throw exceptions with values (not just tags).
An JS typed array (uint_16) is used to hold thrown values, so that the
thrown values can be inspected in JS.
Bug: v8:6577
Change-Id: I1007e79ceaffd64386b62562919cfbb920fc10c5
Reviewed-on: https://chromium-review.googlesource.com/633866
Commit-Queue: Karl Schimpf <kschimpf@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48001}
SetForceInlineFlag is now only used in tests. Earlier, it was also used
in js builtins, because unless this flag was specified the js builtins
were not inlined. All the performance critical js builtins are moved
to turbofan builtins and SetForceInlineFlag is no longer used. We would
like to remove this flag completely to simplify inlining heuristics.
Also, this uses a bit on the SharedFuntionInfo.
Bug: v8:6682
Change-Id: I19afd27381afc212f29179f2c5477095c8174f39
Reviewed-on: https://chromium-review.googlesource.com/660739
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47997}
Before we used to require compiled debugger script to report Scopes.
After migration inspection to brand-new native API we can report
Scopes all the time and remove this hidden dependency.
R=dgozman@chromium.org
Bug: none
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I3530bc7ead691a51073e384aea4a4ef428dc94da
Reviewed-on: https://chromium-review.googlesource.com/662097
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47982}
This continues to move the "desugaring" of unary operators further
down the pipeline, in this case into the bytecode handlers for new
bytecodes `Negate` and `BitwiseNot` and the corresponding TF code
in BytecodeGraphBuilder.
Bug: v8:6971
Tbr: yangguo@chromium.org
Change-Id: If6b5d6b239a09ef8b4dbde49321614503c0f5beb
Reviewed-on: https://chromium-review.googlesource.com/661146
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47980}
As part of that change, make ToNumber return in the accumulator.
Bug: v8:6791
Change-Id: I8ce0f4fbc7ad8ee7fb4a32a8a499394395010750
Reviewed-on: https://chromium-review.googlesource.com/658082
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47976}
So far we didn't properly constant-fold JSToString operators in
JSTypedLowering where the input was a known number constant.
Bug: v8:6815
Change-Id: Iac87346b7d38f0f75461f285ea7daa2d5a5e1524
Reviewed-on: https://chromium-review.googlesource.com/663358
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47972}
This further reduces the amount of test-specific code. It will also
help testing the wasm baseline compiler, since it is also being called
from the {WasmCompilationUnit}.
Also, move the {RuntimeExceptionSupport} flag from the
{WasmFunctionCompiler} to the {TestingModuleBuilder}. There is no need
to store this per function builder. The {TestingModuleBuilder} then
passes it on to the {WasmCompilationUnit}, which finally sets it on the
{WasmGraphBuilder}.
R=mtrofin@chromium.org
Bug: v8:6600
Change-Id: I783dc296297a5ca37a2dd0d2035d782ca19a0fee
Reviewed-on: https://chromium-review.googlesource.com/660239
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47970}
We were using a boolean before, which makes the meaning non-obvious
when passed as a parameter. With the enum, you actually have to use
{kRuntimeExceptionSupport} or {kNoRuntimeExceptionSupport}.
R=mtrofin@chromium.org
Change-Id: Iaf5a7b6f1b446d4c3e16e044a6055d923d3b0b49
Reviewed-on: https://chromium-review.googlesource.com/660738
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47969}
