There was a data race in the access of the foreground_task_runner_map_.
I protect each access to foreground_task_runner_map_ with a lock now.
Original change's description:
> [platform] Implement TaskRunners in the DefaultPlatform
>
> This CL implements the TaskRunners in the DefaultPlatform which has been
> added recently to the platform API. In addition I changed how task
> posting works on the DefaultPlatform.
>
> With this implementation the DefaultPlatform keeps one
> DefaultForegroundTaskRunner per isolate, plus one
> DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
> with a shared_ptr, which is also shared with any caller of
> GetForegroundTaskRunner or GetBackgroundTaskrunner.
>
> This CL moves the task management from the DefaultPlatform to the
> TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
> task queue, the delayed task queue, and the idle task queue. The
> DefaultBackgroundTaskRunner owns the WorkerThread pool and the
> background task queue.
>
> In addition changed many Task* to std::unique_ptr<Task> to document task
> ownership.
>
> R=rmcilroy@chromium.org
>
> Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
> Reviewed-on: https://chromium-review.googlesource.com/753583
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49354}
Change-Id: Iddccdb07bde1a799815ec6ed6af37082df4987c7
Reviewed-on: https://chromium-review.googlesource.com/770970
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49379}
This reverts commit 8de2e6db02.
Reason for revert: Suspect for:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20nosnap%20-%20shared/builds/24237https://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/20896
Original change's description:
> [platform] Implement TaskRunners in the DefaultPlatform
>
> This CL implements the TaskRunners in the DefaultPlatform which has been
> added recently to the platform API. In addition I changed how task
> posting works on the DefaultPlatform.
>
> With this implementation the DefaultPlatform keeps one
> DefaultForegroundTaskRunner per isolate, plus one
> DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
> with a shared_ptr, which is also shared with any caller of
> GetForegroundTaskRunner or GetBackgroundTaskrunner.
>
> This CL moves the task management from the DefaultPlatform to the
> TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
> task queue, the delayed task queue, and the idle task queue. The
> DefaultBackgroundTaskRunner owns the WorkerThread pool and the
> background task queue.
>
> In addition changed many Task* to std::unique_ptr<Task> to document task
> ownership.
>
> R=rmcilroy@chromium.org
>
> Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
> Reviewed-on: https://chromium-review.googlesource.com/753583
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49354}
TBR=rmcilroy@chromium.org,ahaas@chromium.org
Change-Id: I6c381915a2cae8ea1a0d21d6cfa6e797ccd2d947
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/768748
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49357}
This CL implements the TaskRunners in the DefaultPlatform which has been
added recently to the platform API. In addition I changed how task
posting works on the DefaultPlatform.
With this implementation the DefaultPlatform keeps one
DefaultForegroundTaskRunner per isolate, plus one
DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
with a shared_ptr, which is also shared with any caller of
GetForegroundTaskRunner or GetBackgroundTaskrunner.
This CL moves the task management from the DefaultPlatform to the
TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
task queue, the delayed task queue, and the idle task queue. The
DefaultBackgroundTaskRunner owns the WorkerThread pool and the
background task queue.
In addition changed many Task* to std::unique_ptr<Task> to document task
ownership.
R=rmcilroy@chromium.org
Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
Reviewed-on: https://chromium-review.googlesource.com/753583
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49354}
- Remove weak-collection.js
- Adds TFJ builtins for WeakSet and WeakMap constructors
- Unified helpers and constructor behavior into a BaseCollectionsAssembler
- Fast paths for...
- unmodified constructor function
- argument is a fast JS array
- entries are fast JS arrays, for Map/WeakMap
- no arguments passed
Quick benchmarks shows significant improvements (1.12x - 5.7x!) for ALL collection constructors (weak and non-weak):
https://github.com/peterwmwong/v8-perf/blob/master/weakcollection-constructor/README.md
More could be done for performance. Currently we always call out to JS to add entries, if we knew the prototype was unmodified, we could call the builtins directly.
Bug: v8:5049, v8:6604
Change-Id: Id7912c1eed5bcf512df7fd6238f04166a8a5937e
Reviewed-on: https://chromium-review.googlesource.com/760385
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49343}
Since each Array literal containing a spread is individually queued for
rewriting, there's no need for an AstVisitor here: a simple linear
pass through the queue is sufficient.
This patch deletes AstExpressionRewriter and all the machinery supporting
it in the AST. This code was built with the idea of using it as
a general expression rewriting mechanism in the parser, but those use
cases never materialized, and Array spread remains the only thing
that used this code.
Bug: v8:6092
Change-Id: I754c4883099e840881b005f20216f86e57721d5a
Reviewed-on: https://chromium-review.googlesource.com/765051
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49337}
We'll use one generic isolate for all number fuzzers. The previous
deopt isolate will be deleted, once the infra hooks have changed.
Bug: v8:6917
Change-Id: I809613548cd935a0208febb002572cc063697324
Reviewed-on: https://chromium-review.googlesource.com/763534
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49297}
Thanks Igor and Jakob for the hard work to migrate ICs to data-driven handlers!
This is done as of this CL.
Bug: v8:5561
Change-Id: Icf1ddf0065e3aa85ac7efe4b99f74821ce3c0ac2
Reviewed-on: https://chromium-review.googlesource.com/756842
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49203}
This commit updates the jobs for generating postmortem
metadata. I96a8a7cdded6f7c37b6f1da659d63df9e3a5de2b moved
the Code class to a new file without updating the postmortem
jobs. This resulted in some constants used by Node.js to
disappear, leading to build failures on SmartOS.
See: https://github.com/nodejs/node-v8/issues/21
Bug:
Change-Id: Icf5f59fe464d933c4f5a3f622b08c01bc43c6a80
Reviewed-on: https://chromium-review.googlesource.com/741919
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49168}
This is a reland of a9a50dc9a8
Buildbot crashes are fixed by a274fc6.
Original change's description:
> [heap] Temporarily disable concurrent marking.
>
> The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
> large for back merging.
>
> This CL will be back-merged to 6.3 after getting Canary coverage.
>
> Concurrent marking will be re-enabled afterwards.
>
> Bug: chromium:774644
> Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
> Reviewed-on: https://chromium-review.googlesource.com/749811
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49080}
Bug: chromium:774644
Change-Id: Idf5d179eca25a1481c70c6ca3bccde4869deb544
Reviewed-on: https://chromium-review.googlesource.com/751271
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49090}
This reverts commit a9a50dc9a8.
Reason for revert: buildbot crashes.
Original change's description:
> [heap] Temporarily disable concurrent marking.
>
> The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
> large for back merging.
>
> This CL will be back-merged to 6.3 after getting Canary coverage.
>
> Concurrent marking will be re-enabled afterwards.
>
> Bug: chromium:774644
> Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
> Reviewed-on: https://chromium-review.googlesource.com/749811
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49080}
TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org
Change-Id: Ia9d2128c01b811073c1c8f0392eb13b7d7745cd1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:774644
Reviewed-on: https://chromium-review.googlesource.com/751501
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49083}
The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
large for back merging.
This CL will be back-merged to 6.3 after getting Canary coverage.
Concurrent marking will be re-enabled afterwards.
Bug: chromium:774644
Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
Reviewed-on: https://chromium-review.googlesource.com/749811
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49080}
Add the --trace-feedback-updates flag (disabled by default, enabled by
the v8_enable_trace_feedback_updates gn arg), which traces updates to
feedback slots.
Change-Id: Ib8f02f958e2adf04abda5d4ed680e29fa04895ab
Reviewed-on: https://chromium-review.googlesource.com/725814
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48983}
This is the first step towards lazy-deserializing bytecode handlers.
Bytecode handler code objects are now serialized into the builtins
snapshot area (which, like many other related concepts, has become
somewhat of a misnomer now that it contains both builtins and
handlers).
Handlers are still eagerly-deserialized upon Isolate creation. This will
change in follow-up CLs.
Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I7b257f76f5e9e90d5f7b183980bae7bc621171fc
Reviewed-on: https://chromium-review.googlesource.com/738030
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48977}
The current_cpu value was erroneously removed from the build config json.
In multi-arch builds, each toolchain subdirectory in the build-product
output emits its own build-config json, where current_cpu determines
the architecture type of the sub-build.
Correctness-fuzzer runs could wrongly determined x86 sub-builds as x64.
Bug: chromium:777285
Change-Id: I5104630cd8ebbd263d557fb29771a31a2a1d78c2
Reviewed-on: https://chromium-review.googlesource.com/737797
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48950}
Port 266e803ea9
Original Commit Message:
This CL adds a first implementation of Liftoff, the new wasm baseline
compiler, for x64 and ia32. It currently supports the most important
i32 instructions and control instructions. Whenever it encounters an
instruction it does not support yet, it aborts.
In a subsequent CL, Liftoff will be called from the
WasmCompilationUnit, falling back to Turbofan compilation if the
baseline compiler bails out.
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, clemensh@chromium.org, titzer@chromium.org
BUG=
LOG=N
Change-Id: I35ad2b0230c37f523e24aa90b637a67e5ce59083
Reviewed-on: https://chromium-review.googlesource.com/735784
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48935}
This CL adds a first implementation of Liftoff, the new wasm baseline
compiler, for x64 and ia32. It currently supports the most important
i32 instructions and control instructions. Whenever it encounters an
instruction it does not support yet, it aborts.
In a subsequent CL, Liftoff will be called from the
WasmCompilationUnit, falling back to Turbofan compilation if the
baseline compiler bails out.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ifa78fb9d546dce72c241ff01a251dfa13cb31c1d
Reviewed-on: https://chromium-review.googlesource.com/716480
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48832}
Encapsulates special reservation / allocation behavior for builtin
serialization.
This allows us to remove special logic around kNextChunk in builtin
deserialization (since we don't generate that bytecode anymore for
builtins).
Bug: v8:6624
Change-Id: Ice7673006cee53b9d11cdfb7f84d4175221c7984
Reviewed-on: https://chromium-review.googlesource.com/720357
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48725}
This ports the build_config json from GN to GYP to prepare deprecating
tedious flags passing to the test runner.
This also removes two unused GN flags that only hold temporary values.
Bug: v8:6917
Change-Id: I976185f1541277dc5c9bfbaa7578f35c19dd254c
Reviewed-on: https://chromium-review.googlesource.com/725706
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48715}
A continuation of the work in 59e4b751, this extracts logic around
memory reservation and allocations out of the Deserializer class.
Follow-up work is planned to create a specialized allocator for
builtin deserialization.
Bug: v8:6624
Change-Id: I7081cdc557ab8fb2571aadb816399e136ea2cdbb
Reviewed-on: https://chromium-review.googlesource.com/716036
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48634}
Port the baseline version of Reflect.has to the CodeStubAssembler and
reuse the existing logic for HasProperty (i.e. the HasProperty builtin).
Also inline the Reflect.has builtin into TurboFan, by adding a check
on the target in front of a use of the JSHasProperty operator.
Technically this additional check is not necessary, because the
JSHasProperty operator already throws if the target is not a JSReceiver,
but the exception message is confusing then.
This improves the performance of the micro-benchmark from
reflectHasPresent: 337 ms.
reflectHasAbsent: 472 ms.
to
reflectHasPresent: 121 ms.
reflectHasAbsent: 216 ms.
which is a nice 2.8x improvement in the best case. It also improves the
chai test on the web-tooling-benchmark by around 1-2%, which is roughly
the expected win (since Reflect.has overall accounts for around 3-4%).
Bug: v8:5996, v8:6936, v8:6937
Change-Id: I856183229677a71c19936f06f2a4fc7a794a9a4a
Reviewed-on: https://chromium-review.googlesource.com/720959
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48608}
This file was somehow inexplicably not moved when other parsing files were.
BUG=v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iea92c61f83dbb5a8688c404ba87d35fa58e749b9
Reviewed-on: https://chromium-review.googlesource.com/718197
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48522}
This makes all inline allocation constructions go through the existing
{AllocationBuilder} helper class. It hence ensures there is a single
place for all sanity checking and and makes use-sites easier to read.
R=jarin@chromium.org
Change-Id: Ib5daf48acd93c631fccdfa095eda1afda7048115
Reviewed-on: https://chromium-review.googlesource.com/709056
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48502}
Sometimes, the embedder might want to merge a fix to an abandoned branch
or to a supported branch but the fix is not relevant to Chromium.
This adds a new version string that the embedder can set at compile time
and that will be appended to the official V8 version.
The separator must be provided in the string. For instance, to have a
full version string like "6.0.287.53-emb.1", the embedder must set
V8_EMBEDDER_STRING to "-emb.1".
Related Node.js issue: https://github.com/nodejs/node/pull/9754
BUG=v8:5740
R=machenbach@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifa2d9bd213795e6d54886436f8c3787ac6162823
Reviewed-on: https://chromium-review.googlesource.com/690475
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michaël Zasso <mic.besace@gmail.com>
Cr-Commit-Position: refs/heads/master@{#48301}
With --wasm-trace-memory, both compiled code and the interpreter will
output each memory load or store. This helps to debug miscompilations in
emscripten or in V8, like the referenced bug.
R=titzer@chromium.org
Bug: chromium:718858
Change-Id: I90704d164975b11c65677f86947ab102242d5153
Reviewed-on: https://chromium-review.googlesource.com/684316
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48255}
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}
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}
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}
This changes CPU check to use 'target_cpu' instead of 'v8_target_cpu'.
Bug: chromium:694255
Change-Id: Ic3ad5253e4e0b66b13e9f16a5842bcf49881fa52
Reviewed-on: https://chromium-review.googlesource.com/677994
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48119}
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}
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 CL refactors allocation & reservation logic into a new
DefaultSerializerAllocator class. In upcoming work, this will be
further extended by a custom allocator for builtin serialization.
Additionally, this cleans up a bunch of cosmetics (encapsulation and
other nits).
Bug: v8:6624
Change-Id: Ibcf12a525c8fcb26d9c16b7a12fd598c37a0e10a
Reviewed-on: https://chromium-review.googlesource.com/650357
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48077}
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 is a reland of dbfdd4f9e9
Original change's description:
> [heap] Turn on v8_enable_csa_write_barrier
>
> With this commit, write barrier is switched to use CodeStubAssembler.
>
> Bug: chromium:749486
> Change-Id: I7e0914bee971e4f3a3257740ae7c83b31f791bd9
> Reviewed-on: https://chromium-review.googlesource.com/598088
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
> Cr-Commit-Position: refs/heads/master@{#48006}
Bug: chromium:749486
Change-Id: I00933d989568c82b5fbaf6203bb146c65f8e4282
Reviewed-on: https://chromium-review.googlesource.com/668636
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48045}
This reverts commit dbfdd4f9e9.
Reason for revert: https://clusterfuzz.com/v2/testcase-detail/5493096547876864?noredirect=1
Original change's description:
> [heap] Turn on v8_enable_csa_write_barrier
>
> With this commit, write barrier is switched to use CodeStubAssembler.
>
> Bug: chromium:749486
> Change-Id: I7e0914bee971e4f3a3257740ae7c83b31f791bd9
> Reviewed-on: https://chromium-review.googlesource.com/598088
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
> Cr-Commit-Position: refs/heads/master@{#48006}
TBR=ulan@chromium.org,albertnetymk@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:749486
Change-Id: I8cf6a3f1d2ea607a0160b37b797d743b88b004b5
Reviewed-on: https://chromium-review.googlesource.com/667018
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48036}
This was supposedly a runtime flag, but we baked it into the snapshot
anyway.
Change-Id: I09d43183c4c2d59336c1077089119d6cb65dfd87
Reviewed-on: https://chromium-review.googlesource.com/664721
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48026}
With this commit, write barrier is switched to use CodeStubAssembler.
Bug: chromium:749486
Change-Id: I7e0914bee971e4f3a3257740ae7c83b31f791bd9
Reviewed-on: https://chromium-review.googlesource.com/598088
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48006}
Previously instructions-arm64.h was alternatively defining or declaring
some constants based on whether or not ARM64_DEFINE_FP_STATICS was defined,
and it was assumed that exactly one file would include this header with
the macro defined.
In jumbo builds, the header guards in instructions-arm64.h meant that the
resulting state of the header file would be whichever of the two cases
that appeared first in the compilation unit. This would cause multiple
definitions in some cases and no definitions in some other cases (or if
you were really lucky, it would work out ok).
Let's move these constants to a separate source file temporarily, to be
excluded from jumbo compilation units. This code should eventually be
replaced with a cleaner solution.
Bug: chromium:746958
Change-Id: I7edb1821ef408afd50c6b236d63d3c07f955b58f
Reviewed-on: https://chromium-review.googlesource.com/663898
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48003}
BigInt is a new primitive type of arbitrary precision integers,
proposed in https://tc39.github.io/proposal-bigint.
This CL introduces a corresponding instance type, map, and C++
class to V8 and adds BigInt support to a few operations (see the
test file). Much more is to come. Also, the concrete representation
of BigInts is not yet fixed, currently a BigInt is simply a wrapped
Smi.
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45
Reviewed-on: https://chromium-review.googlesource.com/657022
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47956}
TSAN finds data races in generated JavaScript code that use
access the SharedArrayBuffer backing store racily. These are races, but
they are OK in the sense that the JavaScript memory model allows for the
potential bad behavior they could introduce (e.g. potentially tearing
reads). Relaxed atomics could be used here instead, but that could
introduce performance regressions.
This change adds TSAN annotations to the TypedArray reads/writes to
prevent TSAN from warning about them.
Bug: chromium:722871
Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
Reviewed-on: https://chromium-review.googlesource.com/656509
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47929}
This removes the ability to create a copy of a code-stub with a given
replacement pattern applied. It is in preparation of having the ability
to write-protect code objects.
R=ishell@chromium.org
BUG=v8:6409
Change-Id: Id7528b3bfc53ece73d8c58b0ac96c6e5702a9d45
Reviewed-on: https://chromium-review.googlesource.com/654605
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47914}
This finally allows to include the factory.h header without having to
also inlcude the object-inl.h inline header. It will in turn enable the
removal of the last inline header inclusion violation.
R=marja@chromium.org
Change-Id: Ice2821e1f74cf428d80c8ebf606a218026f37677
Reviewed-on: https://chromium-review.googlesource.com/654862
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47880}
This reduces the arm32 binary by around 20kB.
R=jkummerow@chromium.org, mstarzinger@chromium.org
Bug: v8:6055
Change-Id: If9098e49793b29dceb8292aff6f668ca28a07728
Reviewed-on: https://chromium-review.googlesource.com/652427
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47863}
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like
for (var k in o) {
var v = o[k];
// ...
}
and code like
for (var k in o) {
if (Object.prototype.hasOwnProperty.call(o, k)) {
var v = o[k];
// ...
}
}
which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.
For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:
forIn: 1516 ms.
forInHasOwnProperty: 1674 ms.
forInHasOwnPropertySafe: 1595 ms.
forInSum: 2051 ms.
forInSumSafe: 2215 ms.
Compared to numbers from V8 5.8 which is the last version running with
Crankshaft
forIn: 1641 ms.
forInHasOwnProperty: 1719 ms.
forInHasOwnPropertySafe: 1802 ms.
forInSum: 2226 ms.
forInSumSafe: 2409 ms.
and V8 6.0 which is the current stable version with TurboFan:
forIn: 1713 ms.
forInHasOwnProperty: 5417 ms.
forInHasOwnPropertySafe: 5324 ms.
forInSum: 7556 ms.
forInSumSafe: 11067 ms.
It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.
For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.
This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.
Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
heap-inl.h exposes the whole world, which is fine from other inline
files but not from regular headers.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I09ec67c6558682cb0d5181031bc39341a3f4c5bf
Reviewed-on: https://chromium-review.googlesource.com/643294
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47729}
This is a reland of 49e3bfd572
Original change's description:
> [snapshot] Move builtins to dedicated snapshot area
>
> As a first step towards lazy builtin deserialization, this CL moves
> builtins to their own dedicated area in the snapshot blob, physically
> located after startup data and before context-specific data.
>
> The startup- and partial serializers now serialize all seen builtins as
> references, i.e. they only encode the relevant builtin id (taking care
> to preserve special behavior around the interpreter trampoline and
> CompileLazy). Builtins are later fully serialized by the
> BuiltinSerializer. The separate blobs are finally glued together by
> CreateSnapshotBlob.
>
> Deserialization takes the same steps: when we see builtin reference
> bytecodes before builtins have been deserialized, we push to a list of
> deferred builtin references. After builtin deserialization, this list is
> iterated and all builtin references are fixed up.
>
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
> Reviewed-on: https://chromium-review.googlesource.com/610225
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47596}
Bug: v8:6624
Change-Id: I8bfac56c482d992987c270bf0fea7acd9e4ca0c7
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/638271
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47705}
Daniel Bratell reports:
> v8 had a couple of files that were very slow to compile before jumbo
> and if those now end up in the same translation unit, then I can see
> how that translation unit can take an extreme time to get through
> the compiler.
>
> From one of my test builds (times in seconds):
> 49.7 v8_base/objects.o
> 44.0 v8_base/code-stub-assembler.o
> 32.9 v8_base/api.o
> 30.5 v8_base/elements.o
> 25.9 v8_builtins_generators/builtins-regexp-gen.o
> 22.8 v8_base/parser.o
> 21.2 v8_base/heap.o
>
> All of these are in the slowest 0.1% ninja jobs so they are extreme
> in some way. I think I would just exclude them all (or at least the
> 30s+ ones) completely from jumbo.
BUG=chromium:746958
Change-Id: I01741109def4f9ac7c946319374076eb7b9d03b6
Reviewed-on: https://chromium-review.googlesource.com/637971
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47703}
This reverts commit 49e3bfd572.
Reason for revert: Primary suspect for blocked roll: 759552
Original change's description:
> [snapshot] Move builtins to dedicated snapshot area
>
> As a first step towards lazy builtin deserialization, this CL moves
> builtins to their own dedicated area in the snapshot blob, physically
> located after startup data and before context-specific data.
>
> The startup- and partial serializers now serialize all seen builtins as
> references, i.e. they only encode the relevant builtin id (taking care
> to preserve special behavior around the interpreter trampoline and
> CompileLazy). Builtins are later fully serialized by the
> BuiltinSerializer. The separate blobs are finally glued together by
> CreateSnapshotBlob.
>
> Deserialization takes the same steps: when we see builtin reference
> bytecodes before builtins have been deserialized, we push to a list of
> deferred builtin references. After builtin deserialization, this list is
> iterated and all builtin references are fixed up.
>
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
> Reviewed-on: https://chromium-review.googlesource.com/610225
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47596}
TBR=yangguo@chromium.org,mlippautz@chromium.org,jgruber@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6624
Change-Id: I9906c9ea15a623226b890f63bc65876a6f5203f8
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/638331
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47648}
As a first step towards lazy builtin deserialization, this CL moves
builtins to their own dedicated area in the snapshot blob, physically
located after startup data and before context-specific data.
The startup- and partial serializers now serialize all seen builtins as
references, i.e. they only encode the relevant builtin id (taking care
to preserve special behavior around the interpreter trampoline and
CompileLazy). Builtins are later fully serialized by the
BuiltinSerializer. The separate blobs are finally glued together by
CreateSnapshotBlob.
Deserialization takes the same steps: when we see builtin reference
bytecodes before builtins have been deserialized, we push to a list of
deferred builtin references. After builtin deserialization, this list is
iterated and all builtin references are fixed up.
Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
Reviewed-on: https://chromium-review.googlesource.com/610225
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47596}
The v8_enable_fast_mksnapshot gn flag reduces time spent in mksnapshot
on x64 debug builds from 19s to 6s by disabling far jump rewrites and
register allocation verification. This flag should only be used locally
for development.
Bug: v8:6688
Change-Id: I02e8546a6a329b9cb377b95ab586d5857a3c6731
Reviewed-on: https://chromium-review.googlesource.com/632258
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47573}
This reverts commit 8bbc224243.
Reason for revert: On Canary 3195.
Original change's description:
> [heap] Enable concurrent marking for x86 and x64.
>
> This is an experiment and will be reverted after getting canary
> coverage.
>
> Bug: chromium:694255
> Change-Id: I40388d8c6db0e46e2ce64e88aba04c5ac8822e94
> Reviewed-on: https://chromium-review.googlesource.com/625959
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47541}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: I642c1f778267a795bf1e1a6bba863552394ad1d4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:694255
Reviewed-on: https://chromium-review.googlesource.com/631717
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47564}
This is an experiment and will be reverted after getting canary
coverage.
Bug: chromium:694255
Change-Id: I40388d8c6db0e46e2ce64e88aba04c5ac8822e94
Reviewed-on: https://chromium-review.googlesource.com/625959
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47541}
This moves Module and other module-related classes and definitions out
of src/objects{.h,-inl.h,.cc} into src/objects/module{.h,-inl.h,.cc}.
Also moves the contents of src/objects/module-info.h there.
R=marja@chromium.org
Bug: v8:1569, v8:5402
Change-Id: I49064bb4a5c5a6f409274c287e06e8dda351d615
Reviewed-on: https://chromium-review.googlesource.com/626818
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47540}
Deletes the now unused Full-codegen compiler. Also removes some macro
assembler instructions which are no longer used.
Note: there is still additional cleanup work to do after this lands
(e.g., remove support for FCG frames support and FCG
debugger support, etc.), but this will be done in followup CLs to keep
this patch managable.
BUG=v8:6409
Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
Reviewed-on: https://chromium-review.googlesource.com/584773
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47307}
