Move write barrier essentials into heap/heap-write-barrier-inl.h. Avoid
including further heap inline headers by relying on constant to load
flags from.
Bug: v8:7490
Change-Id: I2891299f1b1ca2c3e2031cb9c63b583b1665e3f9
Reviewed-on: https://chromium-review.googlesource.com/1148448
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54710}
This reverts commit fdf69d53b6.
Reason for revert: Speculative revert for broken GPU bots:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/Linux%20V8%20FYI%20Release%20%28NVIDIA%29/1638https://ci.chromium.org/p/v8/builders/luci.v8.ci/Mac%20V8%20FYI%20Release%20%28Intel%29/1624
Original change's description:
> [heap] Adds a young generation large object space
>
> This CL adds the young generation lage object spaces and a flag
> --young-generation-large-objects that by default allocates all
> large objects in this space. This is a preparation CL. The space
> is not fully functional.
>
> Bug: chromium:852420
> Change-Id: Ib66d26fa52cda89bf04787084826aeb84b6ec1ac
> Reviewed-on: https://chromium-review.googlesource.com/1099164
> Commit-Queue: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54056}
TBR=ulan@chromium.org,yangguo@chromium.org,hpayer@chromium.org
Change-Id: I175514f806a19c7837022795210625ca40e3c318
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:852420
Reviewed-on: https://chromium-review.googlesource.com/1118038
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54072}
This CL adds the young generation lage object spaces and a flag
--young-generation-large-objects that by default allocates all
large objects in this space. This is a preparation CL. The space
is not fully functional.
Bug: chromium:852420
Change-Id: Ib66d26fa52cda89bf04787084826aeb84b6ec1ac
Reviewed-on: https://chromium-review.googlesource.com/1099164
Commit-Queue: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54056}
Replace all uses of Deoptimizer::BailoutType and CodeEventListener::DeoptKind
with DeoptimizeKind from src/globals.h.
Change-Id: I5b9002583a69bc43d995cacc7619b018e5a70727
Reviewed-on: https://chromium-review.googlesource.com/1097331
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53695}
This avoids embedding {RelocInfo::CODE_TARGET} addresses into WasmCode
by calling a WebAssembly runtime stub instead. The stubs themselves are
not yet independent of the Isolate, but will be made so soon.
Note that this also introduces a proper {compiler::TrapId} to avoid
accidental parameter type confusion with {TrapIf} and {TrapUnless}
operators.
R=clemensh@chromium.org
BUG=v8:7424
Change-Id: I32ef5a1253f336fc739d2192247826e9458456df
Reviewed-on: https://chromium-review.googlesource.com/1086937
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53557}
This CL introduces a new gn argument: v8_enable_pointer_compression which is
false by default. All the changes done in this CL are made under this flag.
Upper half-word of a Smi word must be properly sign-extended according to the
sign of the lower-half containing the actual Smi value.
Bug: v8:7703
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2b52ab49cd18c7c613130705de445fef44c30ac5
Reviewed-on: https://chromium-review.googlesource.com/1061175
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53519}
see crbug.com/841460 , we recently hit some build issues when using
Goma + jumbo builds because of a conflict on the definition of CONST,
v8 defines it in globals.h and including windows.h also defines it. It
should be possible to fix this by adding a bunch of #undef CONST but it
seems a little bit hacky and might not always work (this could only fix
the problem temporary if the jumbo merge limit changes and cause some
include files to get included in a different order).
Renaming the v8 definition of CONST to kConst, this follows the
style guide guidelines: "there is no reason to change old code to use
constant-style names, unless the old names are actually causing a
compile-time problem"
(https://google.github.io/styleguide/cppguide.html#Enumerator_Names)
I also had to turn the PropertyConstness enum into an enum class to
avoid some conflicts (both PropertyConstness and VariableMode define
kConst).
Bug: chromium:841460
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2b70b9095374e88a5ae364cc557b39f20a3ab60f
Reviewed-on: https://chromium-review.googlesource.com/1064197
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sébastien Marchand <sebmarchand@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53413}
This requires changing the way stubs and builtins are encoded in tags, as for
arm64 we only have 26 bits to encode a PC-relative offset. With the previous
encoding scheme the builtin ids were shifted by 16 bits and ended up exceeding
this range.
Change-Id: I0f396390a622ea67b890d2dd47ca12e00092e204
Reviewed-on: https://chromium-review.googlesource.com/1059209
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53262}
- Make FeedbackVector backing store a WeakFixedArray.
- "feedback" is always strong but "extra" might be weak.
- Whenever the handler stored in FeedbackVector is a WeakCell to a transition
Map, replace it with an in-place weak reference.
For a more detailed description of the changes, see the design doc
https://docs.google.com/document/d/1P8cIme2wKszdYt64ObAiuh6pXgLnrrn80Hpl1ejJbOU/edit#heading=h.ijx1oculrikp
BUG=v8:7308
Change-Id: I72c5cf6597ef24d4c22a1fe8e25b67ca196d4ec8
Reviewed-on: https://chromium-review.googlesource.com/1027855
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53051}
Stubs and builtins are very similar. The main differences are that
stubs can be parameterized and may be generated at runtime, whereas
builtins are generated at mksnapshot-time and shipped with the snapshot
(or embedded into the binary).
My main motivation for these conversions is that we can generate
faster calls and jumps to (embedded) builtins callees from (embedded)
builtin callers. Instead of going through the builtins constants table
indirection, we can simply do a pc-relative call/jump.
This also unlocks other refactorings, e.g. removal of
CallRuntimeDelayed.
TBR=mlippautz@chromium.org
Bug: v8:6666
Change-Id: I4cd63477f19a330ec70bbf20e2af8a42fb05fabb
Reviewed-on: https://chromium-review.googlesource.com/1044245
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53027}
This includes the following changes:
- Limit code space to 128 MB.
- Use direct branches wherever possible.
- Where not possible, continue using load literal followed by an indirect
branch.
- Sort RelocInfo by target_address_address for the serializer, since mixing
load literal instructions and branch instructions messes up that order.
- Ensure we always wipe out targets in the serializer (not just for the
snapshot) in order to be able to distinguish between constant pool entries
and branch instructions.
Change-Id: I1a1029ce2a5f72a3a94802daf267d14a42c7c790
Reviewed-on: https://chromium-review.googlesource.com/939175
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Georgia Kouveli <georgia.kouveli@arm.com>
Cr-Commit-Position: refs/heads/master@{#52885}
The idea is to mark all the branches and loads participating in array
bounds checks, and let them contribute-to/use the poisoning register.
In the code, the marks for array indexing operations now contain
"Critical" in their name. By default (--untrusted-code-mitigations),
we only instrument the "critical" operations with poisoning.
With that in place, we also remove the array masking approach based
on arithmetic.
Since we do not propagate the poison through function calls,
we introduce a node for poisoning an index that is passed through
function call - the typical example is the bounds-checked index
that is passed to the CharCodeAt builtin.
Most of the code in this CL is threads through the three levels of
protection (safe, critical, unsafe) for loads, branches and flags.
Bug: chromium:798964
Change-Id: Ief68e2329528277b3ba9156115b2a6dcc540d52b
Reviewed-on: https://chromium-review.googlesource.com/995413
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52883}
This is a reland of f8ae62fe14
Original change's description:
> [heap] Move initial objects into RO_SPACE
>
> This moves:
> * the main oddballs (null, undefined, hole, true, false) as well as
> their supporting maps (also adds hole as an internalized string to make
> this work).
> * most of the internalized strings
> * the struct maps
> * empty array
> * empty enum cache
> * the contents of the initial string table
> * the weak_cell_cache for any map in RO_SPACE (and eagerly creates the
> value avoid writing to it during run-time)
>
> The StartupSerializer stats change as follows:
>
> RO_SPACE NEW_SPACE OLD_SPACE CODE_SPACE MAP_SPACE LO_SPACE
> old 0 0 270264 32608 12144 0
> new 21776 0 253168 32608 8184 0
> Overall memory usage has increased by 720 bytes due to the eager
> initialization of the Map weak cell caches.
>
> Also extends --serialization-statistics to print out separate instance
> type stats for objects in RO_SPACE as shown here:
>
> Read Only Instance types (count and bytes):
> 404 16736 ONE_BYTE_INTERNALIZED_STRING_TYPE
> 2 32 HEAP_NUMBER_TYPE
> 5 240 ODDBALL_TYPE
> 45 3960 MAP_TYPE
> 1 16 BYTE_ARRAY_TYPE
> 1 24 TUPLE2_TYPE
> 1 16 FIXED_ARRAY_TYPE
> 1 32 DESCRIPTOR_ARRAY_TYPE
> 45 720 WEAK_CELL_TYPE
>
> Bug: v8:7464
> Change-Id: I12981c39c82a7057f68bbbe03f89fb57b0b4c6a6
> Reviewed-on: https://chromium-review.googlesource.com/973722
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52435}
Bug: v8:7464
Change-Id: I50427edfeb53ca80ec4cf46566368fb2213ccf7b
Reviewed-on: https://chromium-review.googlesource.com/999654
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52638}
The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.
Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
... to see if it improves things in real-world area.
Change-Id: Icf6a1ff47f35eb3f7e25b549d736f7404148f6ab
Reviewed-on: https://chromium-review.googlesource.com/1004587
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52523}
This reverts commit f8ae62fe14.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20internal%20snapshot/builds/14825
Original change's description:
> [heap] Move initial objects into RO_SPACE
>
> This moves:
> * the main oddballs (null, undefined, hole, true, false) as well as
> their supporting maps (also adds hole as an internalized string to make
> this work).
> * most of the internalized strings
> * the struct maps
> * empty array
> * empty enum cache
> * the contents of the initial string table
> * the weak_cell_cache for any map in RO_SPACE (and eagerly creates the
> value avoid writing to it during run-time)
>
> The StartupSerializer stats change as follows:
>
> RO_SPACE NEW_SPACE OLD_SPACE CODE_SPACE MAP_SPACE LO_SPACE
> old 0 0 270264 32608 12144 0
> new 21776 0 253168 32608 8184 0
> Overall memory usage has increased by 720 bytes due to the eager
> initialization of the Map weak cell caches.
>
> Also extends --serialization-statistics to print out separate instance
> type stats for objects in RO_SPACE as shown here:
>
> Read Only Instance types (count and bytes):
> 404 16736 ONE_BYTE_INTERNALIZED_STRING_TYPE
> 2 32 HEAP_NUMBER_TYPE
> 5 240 ODDBALL_TYPE
> 45 3960 MAP_TYPE
> 1 16 BYTE_ARRAY_TYPE
> 1 24 TUPLE2_TYPE
> 1 16 FIXED_ARRAY_TYPE
> 1 32 DESCRIPTOR_ARRAY_TYPE
> 45 720 WEAK_CELL_TYPE
>
> Bug: v8:7464
> Change-Id: I12981c39c82a7057f68bbbe03f89fb57b0b4c6a6
> Reviewed-on: https://chromium-review.googlesource.com/973722
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52435}
TBR=rmcilroy@chromium.org,yangguo@chromium.org,hpayer@chromium.org,mlippautz@chromium.org,delphick@chromium.org
Change-Id: Ie62a73a5be3b21a15bb46e342acb3e808fbaa4f3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7464
Reviewed-on: https://chromium-review.googlesource.com/999653
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52440}
This moves:
* the main oddballs (null, undefined, hole, true, false) as well as
their supporting maps (also adds hole as an internalized string to make
this work).
* most of the internalized strings
* the struct maps
* empty array
* empty enum cache
* the contents of the initial string table
* the weak_cell_cache for any map in RO_SPACE (and eagerly creates the
value avoid writing to it during run-time)
The StartupSerializer stats change as follows:
RO_SPACE NEW_SPACE OLD_SPACE CODE_SPACE MAP_SPACE LO_SPACE
old 0 0 270264 32608 12144 0
new 21776 0 253168 32608 8184 0
Overall memory usage has increased by 720 bytes due to the eager
initialization of the Map weak cell caches.
Also extends --serialization-statistics to print out separate instance
type stats for objects in RO_SPACE as shown here:
Read Only Instance types (count and bytes):
404 16736 ONE_BYTE_INTERNALIZED_STRING_TYPE
2 32 HEAP_NUMBER_TYPE
5 240 ODDBALL_TYPE
45 3960 MAP_TYPE
1 16 BYTE_ARRAY_TYPE
1 24 TUPLE2_TYPE
1 16 FIXED_ARRAY_TYPE
1 32 DESCRIPTOR_ARRAY_TYPE
45 720 WEAK_CELL_TYPE
Bug: v8:7464
Change-Id: I12981c39c82a7057f68bbbe03f89fb57b0b4c6a6
Reviewed-on: https://chromium-review.googlesource.com/973722
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52435}
This CL changes the poisoning in the interpreter to use the
infrastructure used in the JIT.
This does not change the original flag semantics:
--branch-load-poisoning enables JIT mitigations as before.
--untrusted-code-mitigation enables the interpreter mitigations
(now realized using the compiler back-end), but does not enable
the back-end based mitigations for the Javascript JIT. So in effect
--untrusted-code-mitigation makes the CSA pipeline for bytecode handlers
use the same mechanics (including changed register allocation) that
--branch-load-poisoning enables for the JIT.
Bug: chromium:798964
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: If7f6852ae44e32e6e0ad508e9237f24dec7e5b27
Reviewed-on: https://chromium-review.googlesource.com/928881
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52243}
Moves RO_SPACE to the front of the AllocationSpace enum, so the space
pre-allocation iterations don't miss it. Being at the start of the enum
means that it continues to not be iterated over by any sweeper code,
which iterates from FIRST_GROWABLE_PAGED_SPACE to
LAST_GROWABLE_PAGED_SPACE (renamed from FIRST_PAGED_SPACE and
LAST_PAGED_SPACE).
Bug: v8:7464
Change-Id: I480ba784afbd878552d1cb7f9f5fa57c3b55e004
Reviewed-on: https://chromium-review.googlesource.com/973604
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52177}
This CL renames InterpreterPushArgsMode::kJSFunction to kArrayFunction
because we only ever use it for the array function.
We never use PushArgsThenCall with kArrayFunction mode, so remove the
unused helpers that provide the plumbing there.
This is in preparation for changes to PushArgsThenConstruct, where we
will no longer pass the allocation site as undefined for modes other
than kArrayFunction.
Bug: v8:7503
Change-Id: I86e3333e2ebd912fc8f9b0e4248282330af4b9e2
Reviewed-on: https://chromium-review.googlesource.com/972047
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Mythri Alle <mythria@google.com>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52109}
Exposing it inside Internals was a hack. The downside of this CL is that heap
object tagging is in two places now (v8.h and globals.h).
BUG=v8:7308
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ic7115ab20d67109dd2b62c772d52eeb84fa7d9f7
Reviewed-on: https://chromium-review.googlesource.com/968423
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52093}
Adds a new space RO_SPACE and modifies the serializer and other machinery
to support it.
Currently RO_SPACE has nothing in it, but will eventually contain all the
immovable immutable objects, so the GC can ignore it.
Bug: v8:7464
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ib2ff474699196c138df8c24f7a2248471e30fbac
Reviewed-on: https://chromium-review.googlesource.com/925703
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52053}
ObjectSpace was only referred to in static_asserts and was otherwise
removed in http://codereview.chromium.org/7945009.
AllocationActions's last usage was removed in
https://codereview.chromium.org/1991293002.
Bug: v8:7310
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I2ccbf3b674517bc698b4c92754cd0b251229d342
Reviewed-on: https://chromium-review.googlesource.com/931887
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51763}
Since we only need to store 18 different function kinds,
the bitfield approach was wasting space (requiring 11 bits).
This patch replaces the bitfield with a regular enum, and
updates all the FunctionKind predicates to use comparisons
instead of bitwise ops.
For the small amount of builtin code that depended upon being
able to do masking to determine whether something is a class
constructor, we still store two extra bits on FunctionKind,
which are computed when the SFI is initialized.
If this approach causes performance regressions (i.e., if it
turns out that other code was implicitly depending on masking
for fast checks), we can revert this or address it in
other ways (e.g., by doing similar caching of repeated checks
in the caller).
This is a reland of 42667bab5b.
Bug: v8:7310
Change-Id: I2ec54289ea687399c61d75b7aff2d849861a64f2
Reviewed-on: https://chromium-review.googlesource.com/934864
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51534}
Also delete a bit of dead code depending on dead types.
Change-Id: I6cfc7e2f6c8fd006bd0de054bfc3e9f725996741
Reviewed-on: https://chromium-review.googlesource.com/923083
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51403}
This ensures that breaking on inlined builtins works, even when
compiling concurrently. This CL also introduces the member
Isolate::AbortConcurrentOptimization.
R=sigurds@chromium.org
Bug: v8:178
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ie6cbb48ebde18036888af2dd715862e7a14ddf9d
Reviewed-on: https://chromium-review.googlesource.com/912468
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51384}
This is a reland of dda0419ecd.
Originally reviewed-on: https://chromium-review.googlesource.com/914513
and landed as refs/heads/master@{#51342}.
Bug: v8:6791
Change-Id: I3b3a069da7a0e64c38a81b3110dc5ece4887cb19
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/924665
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51352}
The stock GCC on Ubuntu 16.04 complains these constants
are unused (possibly gcc issue). This CL changes these
to constexpr to workaround gcc errors.
R=clemensh@chromium.org, joransiu@ca.ibm.com
Change-Id: I8c1772e91744bc46ace6bee576b90d40c0cdf41f
Reviewed-on: https://chromium-review.googlesource.com/881554
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#50936}
This adjusts the RunMicrotask logic to invoke CallHandlerInfo microtasks
from CSA land directly (via a runtime function call), instead of bailing
out to C++ for the rest of the microtask queue entries. Even in simple
micro-benchmarks there doesn't seem to be a huge performance difference.
In fact performance get's better when CallHandlerInfo and promises are
mixed, which makes sense, since calling from C++ to JS land is more
expensive than the other way around.
But just in case the runtime function call overhead ever becomes the
bottleneck we can introduce a direct C++ call and setup a handle scope
around it, much like a very simple version of CallApiFunctionStub.
This greatly simplifies the microtask handling and paves the way for
refactoring the queue to significant reduce the GC overhead associated
with promises currently.
Bug: v8:7253
Change-Id: I33adb62a6bada138674d324f36d4be894e27f3c9
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/890441
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50934}
This is somewhat of a revival of what used to be
UnseededNumberDictionary. The difference to NumberDictionary is that
each entry only has two fields (no field for property details) and there
is no header field for a bitfield.
The reason for this change is memory regression introduced when we
removed UnseededNumberDictionary (6e1c57eaa9). We now use
SimpleNumberDictionary for
- slow template instantiation cache
- code stubs table
- value serializer map
- stack frame cache
- type profile source positions
R=ishell@chromium.org, ulan@chromium.org
Bug: chromium:783695
Change-Id: I3cd32e485060bb379fb2279eeefbbbded7455f0e
Reviewed-on: https://chromium-review.googlesource.com/885811
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50869}
Remove final csp instances, missed in the earlier patch due to being outside
the arm64 tree.
Bug: v8:6644
Change-Id: I2b5a2716568949740991c368b64c0a06105e4ff2
Reviewed-on: https://chromium-review.googlesource.com/874310
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Martyn Capewell <martyn.capewell@arm.com>
Cr-Commit-Position: refs/heads/master@{#50698}
This reverts commit 42667bab5b.
Reason for revert: Breaks msvc compile:
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20msvc/builds/908
Original change's description:
> Simplify FunctionKind, saving 4 bits in SharedFunctionInfo
>
> Since we only need to store 18 different function kinds,
> the bitfield approach was wasting space (requiring 11 bits).
>
> This patch replaces the bitfield with a regular enum, and
> updates all the FunctionKind predicates to use comparisons
> instead of bitwise ops.
>
> For the small amount of builtin code that depended upon being
> able to do masking to determine whether something is a class
> constructor, we still store two extra bits on FunctionKind,
> which are computed when the SFI is initialized.
>
> If this approach causes performance regressions (i.e., if it
> turns out that other code was implicitly depending on masking
> for fast checks), we can revert this or address it in
> other ways (e.g., by doing similar caching of repeated checks
> in the caller).
>
> Change-Id: Iebb3214f564ea8bd7b21e78fda33517d63247124
> Reviewed-on: https://chromium-review.googlesource.com/860896
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50559}
TBR=adamk@chromium.org,gsathya@chromium.org
Change-Id: I8e1faa0ca6213d1e70a00fcb417b1bfa35ebd643
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/866310
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50561}
Since we only need to store 18 different function kinds,
the bitfield approach was wasting space (requiring 11 bits).
This patch replaces the bitfield with a regular enum, and
updates all the FunctionKind predicates to use comparisons
instead of bitwise ops.
For the small amount of builtin code that depended upon being
able to do masking to determine whether something is a class
constructor, we still store two extra bits on FunctionKind,
which are computed when the SFI is initialized.
If this approach causes performance regressions (i.e., if it
turns out that other code was implicitly depending on masking
for fast checks), we can revert this or address it in
other ways (e.g., by doing similar caching of repeated checks
in the caller).
Change-Id: Iebb3214f564ea8bd7b21e78fda33517d63247124
Reviewed-on: https://chromium-review.googlesource.com/860896
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50559}
Create a new function kind for initializer functions and ban arguments
if used in such a function.
Bug: v8:5367, v8:7183
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Id3089e587b3d6a25f27224045f250e032b831818
Reviewed-on: https://chromium-review.googlesource.com/850547
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50369}
This makes the code dealing with type feedback more concise and uniform
(at the cost of a few redundant comparisons).
Bug:
Change-Id: If6b98bd1f0dddd392d7b00d65b600127bd30ff7e
Reviewed-on: https://chromium-review.googlesource.com/818984
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50035}
Explain why we still have kNumber in addition to kNumberOrOddball,
although the original motivation, which was Crankshaft, is gone now.
Bug: v8:7109
Change-Id: I33016fbfa96bb0db57473b6d0c720fa1389d11f1
Reviewed-on: https://chromium-review.googlesource.com/817439
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49991}
The CompareOperationFeedback documentation was outdated and there was an
invalid TODO on it that suggested to unify this with the
BinaryOperationFeedback which in retrospect doesn't make a lot of sense.
Bug: v8:7109
Change-Id: Ibf748e242db55430f29d305f1ef1df6d44449481
Reviewed-on: https://chromium-review.googlesource.com/819090
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49990}
This patch adds a field for the speculation mode to Call
nodes, and passes the speculation mode from the CallIC
to the Call node in the byte code graph builder.
Bug: v8:7127
Change-Id: I89fa10643b46143b36776de1d5ba6ebe3fa2c878
Reviewed-on: https://chromium-review.googlesource.com/814537
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49965}
- Implement RunMicrotasks in CSA to prevent a potentially large number
of jumps between C++ and JS code while consuming te queue. Appears to
provide a ~60% speedup in microtask-heavy code, which from limited
testing appears to scale linearly.
The code-stub microtask pump bails out to the old C++ microtask pump
if it encounters a CallHandlerInfo microtask, and remains in C++ for
the remainder of the queue (returning to the JS/stub implementation
after the bailed out queue is exhausted).
- Add a variation of JSEntryStub which enters the new RunMicrotasks code
stub.
- Add a new RunMicrotasks helper to Execution, which uses the
RunMicrotasks entry stub.
Bug:
Change-Id: I4667d4dd633d24455ea5d7cef239da0af1a7365e
Reviewed-on: https://chromium-review.googlesource.com/650486
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49842}
Some uses use uint64_t instead of int64_t to avoid compiler warnings
about illegal narrowing of values with the MSB set.
R=tebbi@chromium.org,mlippautz@chromium.org
Bug: v8:7109
Change-Id: I6e861f48828bd931c451ef336672a260c13ae042
Reviewed-on: https://chromium-review.googlesource.com/803275
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49797}
V8_INT64_C will be cleaned up in a follow-up CL.
R=tebbi@chromium.org,mlippautz@chromium.org
Bug: v8:7109
Change-Id: I6af97e7266039eb443896b404b77b8e2b5de5adb
Reviewed-on: https://chromium-review.googlesource.com/803294
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49790}
Prior to this change, the exponentiation operator was rewritten by the
parser to a call of the Math.pow builtin. However, Math.pow does not
accept BigInt arguments, while the exponentiation operator must accept
them.
This CL
- removes the parser's special treatment of ** and **=, treating them
like any other binary op instead.
- adds a TFC builtin Exponentiate that does the right thing for
all inputs.
- adds interpreter bytecodes Exp and ExpSmi whose handlers call the
Exponentiate builtin. For simplicity, they currently always collect
kAny feedback.
- adds a Turbofan operator JSExponentiate with a typed-lowering to
the existing NumberPow and a generic-lowering to the Exponentiate
builtin. There is currently no speculative lowering.
Note that exponentiation for BigInts is actually not implemented yet,
so we can't yet test it.
Bug: v8:6791
Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
Reviewed-on: https://chromium-review.googlesource.com/785694
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49696}
This is the first step towards wasm code sharing. This CL moves wasm
code generation outside the JavaScript GC heap using the previously -
introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
flag).
See design document: go/wasm-on-native-heap-stage-1
This CL doesn't change other wasm architectural invariants. We still
have per-Isolate wasm code generation, and per-wasm module instance
code specialization.
Bug:v8:6876
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
Reviewed-on: https://chromium-review.googlesource.com/674086
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49689}
Previously, in order to get immortal immovable objects onto
the first page, the serializer would iterate the root list
twice. The first time it would prioritize immortal immovables.
The second time it would serialize the rest.
This does not guarantee that immortal immovable objects
actually end up on the first page, and by now this is not
necessary anymore, since we mark all pages created during
heap init as immortal immovable pages.
R=mlippautz@chromium.org
Change-Id: Ie95fcd779377a75337621ba862bc1a745ed5cbaa
Reviewed-on: https://chromium-review.googlesource.com/768731
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49468}
Port c192569047
Original Commit Message:
We expect no GC between the call to UnwindAndFindHandler and
the call to that handler. We can precalculate the handler entrypoint
and then let the CEntryStub just load and call that address.
The main motivation for this change is the wasm on the native heap
work, and making the CEntryStub able to work with non- Code* values.
R=mtrofin@chromium.org, mstarzinger@chromium.org, bradnelson@chromium.org, titzer@chromium.org, joransiu@ca.ibm.com, bjaideep@ca.ibm.com, michael_dawson@ca.ibm.com
Change-Id: I139fddabef9f601b46dac9011db3ab8e01e3346d
Reviewed-on: https://chromium-review.googlesource.com/752483
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#49107}
We expect no GC between the call to UnwindAndFindHandler and
the call to that handler. We can precalculate the handler entrypoint
and then let the CEntryStub just load and call that address.
The main motivation for this change is the wasm on the native heap
work, and making the CEntryStub able to work with non- Code* values.
Bug: v8:6876
Change-Id: I660f29619edc315afbb537ef3df018865fab7ba4
Reviewed-on: https://chromium-review.googlesource.com/744723
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49084}
Abstract equality comparison of a BigInt and a String converts the
latter to BigInt. This conversion can fail; since we do not want to
pass a context to the comparison function, we must signal such failure
without throwing an exception.
This CL uses the existing ShouldThrow enum to configure behavior of
String-to-BigInt conversion, moving it out of Object into globals.h.
Bug: v8:6791, v8:6979
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibb98675079b8392cf03bbcbbbd5556108500a32d
Reviewed-on: https://chromium-review.googlesource.com/734172
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48946}
and use a newly-introduced "enum class Operation" in all
other places that so far passed Token::Values around.
Also delete some related dead code along the way.
Bug: v8:6921
Change-Id: I062f396d304aa62298cfeff202e3132a4a5597c1
Reviewed-on: https://chromium-review.googlesource.com/736851
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48944}
Since we don't support gcc 2.96-4.0 any more, we can generalize the
V8_INFINITY macro to always use std::numeric_limits<double>::infinity().
This also makes value constexpr on all systems.
R=tebbi@chromium.org
Change-Id: Ifa97dd2ee6d2c1e179c45f60a82d1ea8481e0590
Reviewed-on: https://chromium-review.googlesource.com/725733
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48694}
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}
Change-Id: I891ff57b7a3a47e3371269b123705cdf6391499b
Reviewed-on: https://chromium-review.googlesource.com/648513
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47830}
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}
This reverts commit 1169f55bbc.
Reason for revert: http://crbug.com/758994
Original change's description:
> Remove obsolete kNumber binop feedback.
>
> With the removal of Crankshaft, kNumber has become obsolete as
> BinaryOperationFeedback. Turbofan uses kNumberOrOddball.
>
> Bug:
> Change-Id: If577f5efcc81d7c08f43908f2764ff0ec6f8747c
> Reviewed-on: https://chromium-review.googlesource.com/628376
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47555}
TBR=jkummerow@chromium.org,jarin@chromium.org,neis@chromium.org,mythria@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I1b33f572f3e6865e00d2468bffcce2ea466814b3
Reviewed-on: https://chromium-review.googlesource.com/637711
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47642}
With the removal of Crankshaft, kNumber has become obsolete as
BinaryOperationFeedback. Turbofan uses kNumberOrOddball.
Bug:
Change-Id: If577f5efcc81d7c08f43908f2764ff0ec6f8747c
Reviewed-on: https://chromium-review.googlesource.com/628376
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47555}
For Divide operations like
r = a / b
where r has only truncated uses (i.e. only used in bitwise operations),
we used to generate a Float64Div unless we statically knew something
about a and b, even if a and b have always been integers so far.
Crankshaft was able to generate an integer division here, because
Fullcodegen collected feedback independently for inputs and outputs of
binary operations.
This adds new BinaryOperationFeedback::kSignedSmallInputs, which is used
specifically for Divide to state that we have seen only SignedSmall
inputs thus far, but the outputs weren't always in the SignedSmall
range.
The issue was discovered in a WebGL Triangulation library and reported
via https://twitter.com/mourner/status/895708603117518848 after Node
8.3.0 was released with I+TF.
R=jarin@chromium.org
Bug: v8:6698
Change-Id: I830e421a3bf91fc8fa3665cbb706bc13675a6d2b
Reviewed-on: https://chromium-review.googlesource.com/612063
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47302}
This is a reland of 35c923cc10
Original change's description:
> [heap] Add support for atomic access to page flags.
>
> This patch renames AsAtomicWord to AsAtomicPointer and
> adds new AsAtomicWord that works with intptr_t.
>
> Slot recording uses atomic page flag accessors.
>
> BUG=chromium:694255
>
> Change-Id: I1c692813244b41320182e9eea50462d1802fcd98
> Reviewed-on: https://chromium-review.googlesource.com/597688
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47086}
Bug: chromium:694255
Change-Id: I36780ff4001e068815d4be1e16cd06f1a4f98d13
Reviewed-on: https://chromium-review.googlesource.com/599909
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47131}
This begins splitting up the Deserializer class into
{Object,Partial,Startup}Deserializer. For now, all functionality remains in
the Deserializer base clase, to be refactored in future CLs. Empty .cc files
are added here to avoid having to touch build files again.
Bug: v8:6624
Change-Id: If563e03492991bd55c91cd2e09312c0a26aaab2c
Reviewed-on: https://chromium-review.googlesource.com/598067
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47107}
This patch renames AsAtomicWord to AsAtomicPointer and
adds new AsAtomicWord that works with intptr_t.
Slot recording uses atomic page flag accessors.
BUG=chromium:694255
Change-Id: I1c692813244b41320182e9eea50462d1802fcd98
Reviewed-on: https://chromium-review.googlesource.com/597688
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47086}
Replacing pc with trampoline on stack
This CL is the follow up of https://chromium-review.googlesource.com/c/586707/
which used to crash when running the gc-stress bots.
It seems to be working now. We now keep the trampoline PC in the Safepoint
table and use that information to find SafepointEntries.
There's some refactoring that can be done, such as changing the code for
exceptions in a similar way and removing the trampoline from the
DeoptimizationInputData. Will take care of this in the next CL.
Bug: v8:6563
Change-Id: I8c0a2489de19e6d5fb4ebf1de7da1933726265b4
Reviewed-on: https://chromium-review.googlesource.com/596027
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47066}
This reverts commit a01ac7cbd9.
Reason for revert: Causes flakes on gc stress:
https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/14218
Original change's description:
> Replacing pc with trampoline on stack
>
> This CL is the follow up of https://chromium-review.googlesource.com/c/586707/
> which used to crash when running the gc-stress bots.
> It seems to be working now. We now keep the trampoline PC in the Safepoint
> table and use that information to find SafepointEntries.
>
> There's some refactoring that can be done, such as changing the code for
> exceptions in a similar way and removing the trampoline from the
> DeoptimizationInputData. Will take care of this in the next CL.
>
> Bug: v8:6563
> Change-Id: I02565297093620023a1155b55d76a4dafcb54794
> Reviewed-on: https://chromium-review.googlesource.com/593622
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47030}
TBR=jarin@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: Ie9929c9acae321a91014b76b9008f8835313e67d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6563
Reviewed-on: https://chromium-review.googlesource.com/595927
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47038}
This CL is the follow up of https://chromium-review.googlesource.com/c/586707/
which used to crash when running the gc-stress bots.
It seems to be working now. We now keep the trampoline PC in the Safepoint
table and use that information to find SafepointEntries.
There's some refactoring that can be done, such as changing the code for
exceptions in a similar way and removing the trampoline from the
DeoptimizationInputData. Will take care of this in the next CL.
Bug: v8:6563
Change-Id: I02565297093620023a1155b55d76a4dafcb54794
Reviewed-on: https://chromium-review.googlesource.com/593622
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47030}
This is a reland of 3f90d9f994
Original change's description:
> [Memory] Add an OnCriticalMemoryPressure method to V8::Platform.
>
> Adds virtual V8::Platform::OnCriticalMemoryPressure method, default
> implementation does nothing.
>
> Calls this method on first allocation failures in NewArray, Malloced,
> and zone AccountingAllocator and adds retry logic.
>
> Adds utility functions for allocating base::VirtualMemory to functions
> in allocation.h, which call this method and add retry logic.
>
> Calls these utility functions in heap CodeRange, Spaces, StoreBuffer
> and SequentialMarkingDeque.
>
> Bug: v8:6635
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I38afd394f3be556aca037d16675e9884658158cb
> Reviewed-on: https://chromium-review.googlesource.com/583543
> Commit-Queue: Bill Budge <bbudge@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46988}
Bug: v8:6635
Change-Id: I0d70c5796f407f0ed42cfddf581d26f533f9bea8
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/593090
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47027}
Adds virtual V8::Platform::OnCriticalMemoryPressure method, default
implementation does nothing.
Calls this method on first allocation failures in NewArray, Malloced,
and zone AccountingAllocator and adds retry logic.
Adds utility functions for allocating base::VirtualMemory to functions
in allocation.h, which call this method and add retry logic.
Calls these utility functions in heap CodeRange, Spaces, StoreBuffer
and SequentialMarkingDeque.
Bug: v8:6635
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I38afd394f3be556aca037d16675e9884658158cb
Reviewed-on: https://chromium-review.googlesource.com/583543
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46988}
This reverts commit e15f554427.
Reason for revert: it breaks the GC stress.
Original change's description:
> Changing the return address on the stack.
>
> Rather than patching code, the deoptimizer now replaces the
> return address in the frames with respective trampolines.
> This change required to change the way we search for Safepoint
> entries and for Exception Handlers.
> It's working in architectures: x64, ia32, arm, arm64 and mips.
>
> Bug: V8:6563
> Change-Id: I3cbd4d192c3513f307b3a6a2ac99e60d03c753d3
> Reviewed-on: https://chromium-review.googlesource.com/586707
> Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46967}
TBR=jarin@chromium.org,bmeurer@chromium.org,jupvfranco@google.com
Change-Id: I430fa9123beef2e0723b38cdef9537181203f7e7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: V8:6563
Reviewed-on: https://chromium-review.googlesource.com/591371
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46969}
Rather than patching code, the deoptimizer now replaces the
return address in the frames with respective trampolines.
This change required to change the way we search for Safepoint
entries and for Exception Handlers.
It's working in architectures: x64, ia32, arm, arm64 and mips.
Bug: V8:6563
Change-Id: I3cbd4d192c3513f307b3a6a2ac99e60d03c753d3
Reviewed-on: https://chromium-review.googlesource.com/586707
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46967}
