This patch ports over the spec defined operation `GetOption` from
JavaScript to C++:
https://tc39.github.io/ecma402/#sec-getoption
The JS implementation will be deleted once all it's
users are migrated.
Refactors LocaleConstructor to use this method which fixes some test262
tests. The test262 test status file is updated to reflect this.
Bug: v8:5751, v8:7684
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Ief5eae9b69dcea50062825163ca7658ed20bd0cf
Reviewed-on: https://chromium-review.googlesource.com/1094201
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53652}
JSWeakCollection should use EphemeronHashTable as backing store instead of
ObjectHashTable such that the GC can handle these structures differently in
the future.
Bug: chromium:844008
Change-Id: Icc6df60c975a942877e2507ef45e0d235e5f72be
Reviewed-on: https://chromium-review.googlesource.com/1089063
Commit-Queue: Dominik Inführ <dinfuehr@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53572}
Adds a new flag v8_deprecate_get_isolate that marks
HeapObject::GetIsolate/GetHeap, Handle<T>(T*) and handle<T>(T*) as
[[deprecated]]. Deprecation warnings are not converted to errors so an
entire build can be completed to collect all the warnings.
Also adds a new script tools/collect_deprecation_stats.sh which runs the
build (assuming the flag is set) and collects the number of uses of
deprecated functions. E.g. at the time of upload, we get:
Total deprecated calls: 2265
515 GetHeap
842 GetIsolate
210 handle
698 Handle
Bug: v8:7786
Change-Id: I7043c597fa90bc77759a357ef3c2a5fefe933491
Reviewed-on: https://chromium-review.googlesource.com/1082478
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53475}
Removes use of HeapObject::GetIsolate() from Object::BooleanValue in
preparation for removing the method.
Requires adding Isolate parameter to CommonOperatorReducer constructor.
Bug: v8:7786
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: If735e71df3288bf1eb11576605c2d95a19472181
Reviewed-on: https://chromium-review.googlesource.com/1071653
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53361}
Currently, we context allocate all parameters for generators.
With this CL, we keep arguments on stack (unless they escape to inner
closure) and copy them between the stack and the generator's register
file on suspend/resume. This will save context allocation in most cases.
Note: There is an asymmetry between suspend and resume.
- Suspend copies arguments and registers to the generator.
- Resume copies only the registers from the generator, the arguments
are copied by the ResumeGenerator trampoline.
Bug: v8:5164
Change-Id: I6333898c60abf461b1ab1b5c6d3dc7188fa95649
Reviewed-on: https://chromium-review.googlesource.com/1063712
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53327}
This CL consolidates CopyFromPrototype and RemoveArrayHoles into a
single runtime function. It also creates two small helper functions
that are needed in both pre-processing steps.
Additionally it removes the return value from CopyFromPrototype since
it is no longer needed (it was previously used by a sort post-
processing step that no longer exists).
Bug: v8:7382
Change-Id: I7f9b00c1bc639d2118fdecef9c3b45c2cf010310
Reviewed-on: https://chromium-review.googlesource.com/1051887
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53199}
https://github.com/tc39/proposal-intl-locale
Rename locale property to baseName to better reflect the intented use case and the change in spec.
TBR: bmeurer@chromium.org
Bug: v8:7684
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I91b630b49ce73abcebd6040ec968c91d75cff879
Reviewed-on: https://chromium-review.googlesource.com/1014411
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53193}
Splitting out hash table into a separate file in
b934607d4c caused a performance
regression.
This inlines GetHash and GetSimpleHash to fix the regression.
Bug: chromium:840694, v8:6443
Change-Id: I0466fa017a179ef2375cec4ddec8f04dfba75921
Reviewed-on: https://chromium-review.googlesource.com/1058446
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53170}
This CL adds a counter for sorting non-packed JSArrays where
Object.prototype was modified, or the prototype of the instance
differs from Array.prototype.
This is the V8 side of the change.
The Chromium-side CL: https://crrev.com/c/1051651R=jgruber@chromium.org
Bug: v8:7382
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I3ce9789a5df4bb9af5d1bfc89681fcd112e28e83
Reviewed-on: https://chromium-review.googlesource.com/1051650
Commit-Queue: Simon Zünd <szuend@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53101}
... in order to be able to use it in other constants definitions in the header.
Bug: v8:7570
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Id5d6ae34ab401ecf063bf5897b87b6bb87c24960
Reviewed-on: https://chromium-review.googlesource.com/1032782
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53097}
This moves the internal fields on {WasmExportedFunction} objects from
being properties with private symbols to a separate structure instead.
The new {WasmExportedFunctionData} structure can hang off the underlying
shared function info which is created for each exported function. This
reduces the number of transitions, speeds up instantiation, and makes it
easier to reach them from generated code (in the future).
R=titzer@chromium.org
BUG=v8:7424
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Iaa733b6c9f7bea96246d6680756aa7101669a1a9
Reviewed-on: https://chromium-review.googlesource.com/1047025
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53040}
This reverts commit 2df5e7a7b6.
Reason for revert: Mystery crashes https://bugs.chromium.org/p/chromium/issues/detail?id=838805
Original change's description:
> [parser] Slice the source string where possible
>
> When internalizing string literals (for quoted strings or property names),
> try to create a sliced string of the source string rather than allocating
> a copy of the bytes.
>
> This will not work for string literals that contain escapes (e.g. unicode
> escapes), and currently does not support two-byte strings.
>
> Bug: chromium:818642
> Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
> Reviewed-on: https://chromium-review.googlesource.com/1010282
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52898}
TBR=marja@chromium.org,yangguo@chromium.org,jarin@chromium.org,mlippautz@chromium.org,leszeks@chromium.org,verwaest@chromium.org
Change-Id: I598b6668c43a3e843e2dd8e60852b2b2f3461954
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:818642
Reviewed-on: https://chromium-review.googlesource.com/1039885
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52919}
Original CL: https://crrev.com/c/1018468
During code generation, we generate self-references (i.e. references to
the Code object currently being generated) as references to a temporary
handle. When the final Code object has been allocated, the handle's
location is fixed up and RelocInfo iteration fixes up all references
embedded in the generated code.
This adds support for this mechanism to the builtins constants table
builder. CodeObject() is now a new handle pointing to a dedicated
self-reference marker in order to distinguish between self-references
and references to undefined. In Factory::NewCode, we patch up
the constants table.
TBR=yangguo@chromium.org,mlippautz@chromium.org
Bug: v8:6666
Change-Id: I3fa422c57de99c9851dc7a86394a8387c7c2b397
Reviewed-on: https://chromium-review.googlesource.com/1039366
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52916}
When internalizing string literals (for quoted strings or property names),
try to create a sliced string of the source string rather than allocating
a copy of the bytes.
This will not work for string literals that contain escapes (e.g. unicode
escapes), and currently does not support two-byte strings.
Bug: chromium:818642
Change-Id: I686e5ad36baecd1a84ce5e124118431249b6c980
Reviewed-on: https://chromium-review.googlesource.com/1010282
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52898}
This reverts commit 6379e2a464.
Reason for revert:
https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Win64%2F23855%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2Fmkgrokdump%2F0
Original change's description:
> [builtins] Patch self-references in constants table
>
> During code generation, we generate self-references (i.e. references to
> the Code object currently being generated) as references to a temporary
> handle. When the final Code object has been allocated, the handle's
> location is fixed up and RelocInfo iteration fixes up all references
> embedded in the generated code.
>
> This adds support for this mechanism to the builtins constants table
> builder. CodeObject() is now a new handle pointing to a dedicated
> self-reference marker in order to distinguish between self-references
> and references to undefined. In Factory::NewCode, we patch up
> the constants table.
>
> Bug: v8:6666
> Change-Id: If74ed91bb1c3b8abb20ff2f0a87d1bcd9a1b0511
> Reviewed-on: https://chromium-review.googlesource.com/1018468
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52854}
TBR=yangguo@chromium.org,mlippautz@chromium.org,jgruber@chromium.org
Change-Id: I8cf8c4b43f51285ea913c6c8fdd339bd9ea645df
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6666
Reviewed-on: https://chromium-review.googlesource.com/1033092
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52856}
During code generation, we generate self-references (i.e. references to
the Code object currently being generated) as references to a temporary
handle. When the final Code object has been allocated, the handle's
location is fixed up and RelocInfo iteration fixes up all references
embedded in the generated code.
This adds support for this mechanism to the builtins constants table
builder. CodeObject() is now a new handle pointing to a dedicated
self-reference marker in order to distinguish between self-references
and references to undefined. In Factory::NewCode, we patch up
the constants table.
Bug: v8:6666
Change-Id: If74ed91bb1c3b8abb20ff2f0a87d1bcd9a1b0511
Reviewed-on: https://chromium-review.googlesource.com/1018468
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52854}
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}
Before Turbofan/Ignition it was possible to use external profilers to
sample running V8/Node.js processes and generate reports/FlameGraphs
from that. It's still possible to do so, but non-optimized JavaScript
functions appear in the stack as InterpreterEntryTrampoline. This commit
adds a runtime flag which makes interpreted frames visible on the
process' native stack as distinguishable functions, making the sampled
data gathered by external profilers such as Linux perf and DTrace more
useful.
R=bmeurer@google.com, franzih@google.com, jarin@google.com, yangguo@google.com
Bug: v8:7155
Change-Id: I3dc8876aa3cd9f1b9766624842a7cc354ccca415
Reviewed-on: https://chromium-review.googlesource.com/959081
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52533}
There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.
This saves about 20KB of binary size on x64.
Original review: https://chromium-review.googlesource.com/c/v8/v8/+/959533
Originally landed as r52416 / f9a2e24bbc
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Id072cbe6b3ed30afd339c7e502844b99ca12a647
Reviewed-on: https://chromium-review.googlesource.com/1000540
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52492}
MUST_USE_RESULT was deprecated for some time. This removes it and
replaces all uses by the equivalent V8_WARN_UNUSED_RESULT.
R=mstarzinger@chromium.org
Bug: v8:7570
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I86883218638e64eeeb7a5891904319ed0844a004
Reviewed-on: https://chromium-review.googlesource.com/999533
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52486}
This reverts commit f9a2e24bbc.
Reason for revert: gc stress failures not all fixed by follow up.
Original change's description:
> [cleanup] Refactor the Factory
>
> There is no good reason to have the meat of most objects' initialization
> logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
> this CL changes the protocol between Heap and Factory to be AllocateRaw,
> and all object initialization work after (possibly retried) successful
> raw allocation happens in the Factory.
>
> This saves about 20KB of binary size on x64.
>
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
> Reviewed-on: https://chromium-review.googlesource.com/959533
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52416}
TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/999414
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52420}
There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.
This saves about 20KB of binary size on x64.
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
Reviewed-on: https://chromium-review.googlesource.com/959533
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52416}
In addition, remove the default branch from the swtich in HeapObjectPrint, so
that it's no longer possible to leave out printing functionality by accident.
BUG=v8:7308
Change-Id: I2db67549e328aea6228d3a370f9ebb7494ab3730
Reviewed-on: https://chromium-review.googlesource.com/997492
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52384}
This change implements the WebAssembly.Global object and constructor,
but none of the accessors or functions.
There is a new flag to enable this: --experimental-wasm-mut-global.
Change-Id: Ifeb270d57392d7ca0900c80c0038932c96ee8b61
Reviewed-on: https://chromium-review.googlesource.com/989296
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52335}
Makes CallHandlerInfo its own instance type, with an additional
map to distinguish side-effect-free handlers. In a followup, we
can expose an API flag to set the map.
This CL does not support whitelisting calls to ObjectTemplates
that use SetCallAsFunctionHandler().
Bug: v8:7515
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ie32fe144046a9fae3e3b1ea5602b0da3db8a5616
Reviewed-on: https://chromium-review.googlesource.com/965741
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52328}
We need to bypass shortcuts when executing accessors defined via FunctionTemplate
if we have break points at function entry.
R=ishell@chromium.org, jgruber@chromium.org
Bug: v8:7596
Change-Id: I0e1bdbbba0f7dcd0fb7fe90d35b18234d073fe94
Reviewed-on: https://chromium-review.googlesource.com/980316
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52276}
Almost all callers of BodyDescriptor already have the map of the object
and should pass it to IterateBody and IsValidSlot functions.
This removes redundant load and makes the function consistent with the
SizeOf function.
Change-Id: Ie47a9bb05af23fbf0576dff99f2ec69625e057fc
Reviewed-on: https://chromium-review.googlesource.com/979436
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52218}
This is a reland of 6da438fda1
Original change's description:
> [runtime] introduced instrance type for each context type
>
> Each context type get own instance type:
> - we can make CSA checks more strict in couple places,
> - it is requires step for advanced evaluation without side effects.
>
> R=yangguo@chromium.org
>
> Bug: v8:7588
> Change-Id: I585e8b55a280a909fc3c6069ed30e34b7040d0c7
> Reviewed-on: https://chromium-review.googlesource.com/977041
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52191}
Bug: v8:7588
Change-Id: I80110ff814c0315d7ca694b7d0aef5b10df614f0
Reviewed-on: https://chromium-review.googlesource.com/978584
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52196}
This reverts commit 6da438fda1.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/18287
Original change's description:
> [runtime] introduced instrance type for each context type
>
> Each context type get own instance type:
> - we can make CSA checks more strict in couple places,
> - it is requires step for advanced evaluation without side effects.
>
> R=yangguo@chromium.org
>
> Bug: v8:7588
> Change-Id: I585e8b55a280a909fc3c6069ed30e34b7040d0c7
> Reviewed-on: https://chromium-review.googlesource.com/977041
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52191}
TBR=yangguo@chromium.org,mstarzinger@chromium.org,kozyatinskiy@chromium.org
Change-Id: I17a24b5b99552941d7a8ec54ebf6d11d6d1a66d8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7588
Reviewed-on: https://chromium-review.googlesource.com/977974
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52193}
Each context type get own instance type:
- we can make CSA checks more strict in couple places,
- it is requires step for advanced evaluation without side effects.
R=yangguo@chromium.org
Bug: v8:7588
Change-Id: I585e8b55a280a909fc3c6069ed30e34b7040d0c7
Reviewed-on: https://chromium-review.googlesource.com/977041
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52191}
See the referenced issue for details.
Bug: v8:7559
Change-Id: I16b5d22b484407d277fa55868429f5f11078b56d
Reviewed-on: https://chromium-review.googlesource.com/970361
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52173}
For problems with the current approach, see crbug.com/v8/7564.
We can instead gather all weak references in code in VisitEmbeddedPointer.
BUG=v8:7564, v8:7308
Change-Id: Ib369e7ab9efd62c90bdac69835318929c58217f2
Reviewed-on: https://chromium-review.googlesource.com/968250
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52041}
Adds a flag onto InterceptorInfo to mark an interceptor's getter,
query, and enumerator callbacks as side-effect-free.
Bug: v8:7515
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Iafc5d2fa554d6d9a38604e179ea5b884c3b77af0
Reviewed-on: https://chromium-review.googlesource.com/957870
Commit-Queue: Erik Luo <luoe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51969}
Previously we used a FixedArray for the FeedbackMetadata, packing bits
of information into Smi fields. On 64-bit platforms, we waste at least
half of the available memory by using the Smi representation.
Given that this is just raw data (no pointers), we can just use a new
type that uses the existing packing scheme to store the data in int32
format instead.
This CL changes FeedbackMetadata to a new subclass of HeapObject. This
is to reduce the API surface exposed, in comparison to extending/using
a more general purpose data structure like ByteArray, which is also just
raw data.
FeedbackMetadata only exposes general purpose methods for accessing
slots, but hides the implementation detail of packing bits into int32
fields.
This CL also introduces a sentinal EmptyFeedbackMetadata, because there
are ~750 empty FeedbackMetadata objects when running an empty program in
V8. These are probably for builtins.
Bug: v8:7500
Change-Id: Ic85563153abbd71a22854cee8519260c32b1e9ab
Reviewed-on: https://chromium-review.googlesource.com/945730
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51842}
The next CL will add an actual WeakFixedArray which contains in-place weak
references.
Also removes FLAG_trace_weak_arrays which is not super useful.
BUG=v8:7308
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I016880ecc66b03b406f7184b7f72ab514cb65428
Reviewed-on: https://chromium-review.googlesource.com/951730
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51789}
Instead of a hard-coded list of function addresses, we now use a flag
on the AccessorInfo object to annotate whether the getter can cause any
side effect.
Future changes will extend this to InterceptorInfo, CallHandlerInfo, and
expose this through the API.
R=jgruber@chromium.org, luoe@chromium.org
Bug: v8:7515
Change-Id: Id0fedf03493c3bd81913557a5681f8f63660f6a4
Reviewed-on: https://chromium-review.googlesource.com/945909
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51756}
Implement in-place weak reference handling in GC.
Turn FeedbackVector::optimized_code_or_smi into an in-place weak reference (this
is the only in-place weak reference at this point).
(See bug for design doc.)
BUG=v8:7308
TBR=yangguo@chromium.org
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I16d65dc768f10ed431252e23a0df07bee9063534
Reviewed-on: https://chromium-review.googlesource.com/948493
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51731}
This makes sure that the object can be identified by a unique instance
type and hence is not accidentally confused with other FixedArrays on
the heap.
R=clemensh@chromium.org
BUG=v8:7509
Change-Id: I20521cdcabbbddecd89ca8cd4bb203a47e1db0cd
Reviewed-on: https://chromium-review.googlesource.com/946253
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51730}
This changes the JSArrayIterator to always have only a single instance
type, instead of the zoo of instance types that we had before, and
which became less useful with the specification update to when "next"
is loaded from the iterator now. This greatly simplifies the baseline
implementation of the array iterator, which now only looks at the
iterated object during %ArrayIteratorPrototype%.next invocations.
In TurboFan we introduce a new JSCreateArrayIterator operator, that
holds the IterationKind and get's the iterated object as input. When
optimizing %ArrayIteratorPrototype%.next in the JSCallReducer, we
check whether the receiver is a JSCreateArrayIterator, and if so,
we try to infer maps for the iterated object from there. If we find
any, we speculatively assume that these won't have changed during
iteration (as we did before with the previous approach), and generate
fast code for both JSArray and JSTypedArray iteration.
Drive-by-fix: Drop the fast_array_iteration protector, it's not
necessary anymore since we have the deoptimization guard bit in
the JSCallReducer now.
This addresses the performance cliff noticed in webpack 4. The minimal
repro on the tracking bug goes from
console.timeEnd: mono, 124.773000
console.timeEnd: poly, 670.353000
to
console.timeEnd: mono, 118.709000
console.timeEnd: poly, 141.393000
so that's a 4.7x improvement.
Also make presubmit happy by adding the missing #undef's.
Bug: v8:7510, v7:7514
Change-Id: I79a46bfa2cd0f0710e09365ef72519b1bbb667b5
Reviewed-on: https://chromium-review.googlesource.com/946098
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51725}
Implement in-place weak reference handling in GC.
Turn FeedbackVector::optimized_code_or_smi into an in-place weak reference (this
is the only in-place weak reference at this point).
(See bug for design doc.)
BUG=v8:7308
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0f9f992cb4ee0457c40b7c868317dfb607bfb906
Reviewed-on: https://chromium-review.googlesource.com/873638
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51722}
This CL removes the last method taking a raw callback as argument.
Bug: chromium:782550
Change-Id: Ia7f19120be7dcb2648f11cd3cdb8880f8818490d
Reviewed-on: https://chromium-review.googlesource.com/822198
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51695}
This makes sure that the object can be identified by a unique instance
type and hence is not accidentally confused with other FixedArrays on
the heap.
R=clemensh@chromium.org
BUG=v8:7509
Change-Id: Ib3dcdb4559821d0ad9ca8cced37754e0e3c1d578
Reviewed-on: https://chromium-review.googlesource.com/943781
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51687}
This makes sure that the object can be identified by a unique instance
type and hence is not accidentally confused with other FixedArrays on
the heap.
R=clemensh@chromium.org
BUG=v8:7509
Change-Id: I66e3d779ff9a323b64f5464bdd5fe02aefe468c6
Reviewed-on: https://chromium-review.googlesource.com/943442
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51665}
This is a first step towards using Maps as store transition handlers.
It is expected for this CL to noticeably regress memory consumption
but most of it should be recovered by the next CL.
Bug: v8:5988
Change-Id: Ic2e301f9ccebc36e699383ded8c8cd284a906ce1
Reviewed-on: https://chromium-review.googlesource.com/928646
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51663}
Scavenger::PromoteObject and Scavenger::SemiSpaceCopyObject load and
dereference the map of the object to compute the alignment.
This is unsafe because the object can be already migrated by another
thread and the map word can contain the forwarding address.
This patch removes the map load and uses the provided map argument to
compute the alignment.
Bug: chromium:811278,chromium:807178
Change-Id: I7343344dc65ae26eefb2602c55dee87bb511bc72
Reviewed-on: https://chromium-review.googlesource.com/939172
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51592}
The list of runtime function use counts was generated with:
$ grep -o '^ *F(\w*' src/runtime/runtime.h | sed 's/^ *F(//' | sort | while read f; do USE_COUNT=$(git grep "\(Runtime::k\|Runtime::kInline\|%\|%_\)$f" | wc -l); echo $USE_COUNT $f; done
This reduces libv8.so size by 59K on an x64 release build.
Bug: v8:7310
Change-Id: Ib4d097e63ed065f41bf73e9529e4354575be5229
Reviewed-on: https://chromium-review.googlesource.com/934272
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51526}
This is preparatory cleanup work for eventually tracking the functions
(rather than concrete closures) in the CALL_IC, also for builtins like
the default PromiseCapability [[Resolve]] and [[Reject]] functions. It
adds a new FeedbackCell type, which is used by JSFunctions consistently
now to reference the feedback vector (or undefined if not the function
is not compiled yet or is a native/asm.js function).
This also changes the calling convention for FastNewClosure builtin and
the JSCreateClosure operator in TurboFan to carry the FeedbackCell here
instead of the parent FeedbackVector and the slot index. In addition we
eliminate the now unused %InterpreterNewClosure runtime function.
Bug: v8:2206, v8:7253, v8:7310
Change-Id: Ib4ce456e276e0273e57c163dcdd0b33abf863656
Reviewed-on: https://chromium-review.googlesource.com/928403
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51474}
Private fields should not return undefined on access miss, but instead
should throw a TypeError.
This patch uses a bit on v8::Symbol to mark if this symbol is a
private field or not.
This patch also changes the LookupIterator code path that deals with
LookupIterator::State::DATA to deal with JSReceiver instead of
JSObject.
Note: the error message doesn't output the field name, but that's a
WIP.
Bug: v8:5368
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I8ae960b478eb6ae1ebf9bc90658ce3654d687977
Reviewed-on: https://chromium-review.googlesource.com/905627
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51452}
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 ES2017 specification contains a so-called "throwaway" promise that
is used to specify the behavior of await in terms of PerformPromiseThen,
but it's actually not necessary and never exposed to user code. In
addition to that, hooking up the promise in await required a context (to
refer to the generator object) and two closures for the reject/fulfill
handling, which would resume the generator corresponding to the async
function. That meant, we had to allocate 4 additional objects for every
await.
Instead of using a JSPromise plus the callbacks, this CL adds logic to
allow PromiseReaction and PromiseReactionJobTask to carry arbitrary
payloads and Code handlers. We use this for await to avoid the
additional 4 objects mentioned above, and instead just have simple Code
handlers that resume the generator (for the async function), either by
throwing (in case of a rejection) or by resuming normally (in case of
fulfillment).
For this to work properly the JSGeneratorObject has to have a link to
the outer promise returned by the async function, so that the catch
prediction can still figure out what to do in case of promise rejection.
This is done by adding a new generator_outer_promise_symbol when the
debugger is active, which refers from the generator to the outer
promise.
With this change the doxbee-async-es2017-native test goes from around
100.54ms to around 82.45ms, which corresponds to a ~18% reduction in
execution time.
Bug: v8:7253
Change-Id: Iae25b3300bac351c3417be5ae687eff469b0e61f
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/924069
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51334}
instance_class_name takes up space unnecessarily, and %_ClassOf and
class_name implement [[Class]] which isn't part of ES2015+ anymore.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3a73f732ad83a616817fde9992f4e4d584638fa8
Reviewed-on: https://chromium-review.googlesource.com/776683
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51309}
This introduces dedicated builtins
- FulfillPromise,
- RejectPromise, and
- ResolvePromise,
which perform the corresponding operations from the language
specification, and removes the redundant entry points and the
excessive inlining of these operations into other builtins. We
also add the same logic on the C++ side, so that we don't need
to go into JavaScript land when resolving/rejecting from the
API.
The C++ side has a complete implementation, including full support
for the debugger and the current PromiseHook machinery. This is to
avoid constantly crossing the boundary for those cases, and to also
simplify the CSA side (and soon the TurboFan side), where we only
do the fast-path and bail out to the runtime for the general handling.
On top of this we introduce %_RejectPromise and %_ResolvePromise,
which are entry points used by the bytecode and parser desugarings
for async functions, and also used by the V8 Extras API. Thanks to
this we can uniformly optimize these in TurboFan, where we have
corresponding operators JSRejectPromise and JSResolvePromise, which
currently just call into the builtins, but middle-term can be further
optimized, i.e. to skip the "then" lookup for JSResolvePromise when
we know something about the resolution.
In TurboFan we can also already inline the default PromiseCapability
[[Reject]] and [[Resolve]] functions, although this is not as effective
as it can be right now, until we have inlining support for the Promise
constructor (being worked on by petermarshall@ right now) and/or SFI
based CALL_IC feedback.
Overall this change is meant as a refactoring without significant
performance impact anywhere; it seems to improve performance of
simple async functions a bit, but otherwise is neutral.
Bug: v8:7253
Change-Id: Id0b979f9b2843560e38cd8df4b02627dad4b6d8c
Reviewed-on: https://chromium-review.googlesource.com/911632
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51260}
Most of the users of these api methods manually ensure that the returned
values are Strings. With an additional flag we can easily ensure that already
in V8 and avoid needless api roundtrips.
Bug: v8:7358
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I62165d44084abc9f07f5bdaace5105847edca60a
Reviewed-on: https://chromium-review.googlesource.com/901248
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51250}
Implements the change outlined in https://github.com/tc39/ecma262/pull/890,
which has been ratified and pulled into the specification. In particular,
template callsite objects are no longer kept in a global, eternal Map, but
are instead associated with their callsite, which can be collected. This
prevents a memory leak incurred by TaggedTemplate calls.
Changes, summarized:
- Remove the TemplateMap and TemplateMapShape objects, instead caching
template objects in the feedback vector.
- Remove the `hash` member of TemplateObjectDescriptor, and the Equals
method (used by TemplateMap)
- Add a new FeedbackSlotKind (kTemplateObject), which behaves similarly
to FeedbackSlotKind::kLiteral, but prevents eval caching. This ensures
that a new feedback vector is always created for eval() containing tagged
templates, even when the CompilationCache is used.
- GetTemplateObject bytecode now takes a feedback index, and only calls
into the runtime if the feedback is Smi::kZero (uninitialized).
BUG=v8:3230, v8:2891
R=littledan@chromium.org, yangguo@chromium.org, bmeurer@chromium.org,
rmcilroy@chromium.org
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I7827bc148d3d93e2b056ebf63dd624da196ad423
Reviewed-on: https://chromium-review.googlesource.com/624564
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51248}
This reverts commit 14108f4c2e.
Reason for revert: Not the culprit for Canary microtask crashes
Original change's description:
> [builtins] Mega-revert to address the Dev blocker in crbug.com/808911.
>
> - Revert "[builtins] Save one word in contexts for Promise.all."
> This reverts commit 7632da067b.
> - Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
> This reverts commit d4f072ced3.
> - Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
> This reverts commit 6703dacdd6.
> - Revert "[debugger] Properly deal with settled promises in catch prediction."
> This reverts commit 40dd065823.
> - Revert "[builtins] Widen the fast-path for Promise builtins."
> This reverts commit db0556b7e8.
> - Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
> This reverts commit a582199c5e.
> - Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
> This reverts commit 6bf8885290.
> - Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
> This reverts commit 313b490ddd.
> - Revert "[builtins] Inline InternalPromiseThen into it's only caller"
> This reverts commit f7bd6a2fd6.
> - Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
> This reverts commit b23b098fa0.
> - Revert "[promise] Remove incorrect fast path"
> This reverts commit 0f6eafe855.
> - Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
> This reverts commit 8a677a2831.
> - Revert "[builtins] Refactor promises to reduce GC overhead."
> This reverts commit 8e7737cb58.
>
> Tbr: hpayer@chromium.org
> Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
> Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Reviewed-on: https://chromium-review.googlesource.com/906991
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Adam Klein <adamk@chromium.org>
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#51158}
Change-Id: I09d958cbebd635a325809072a290f2f53df8c5d4
Tbr: adamk@chromium.org,yangguo@chromium.org,bmeurer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/908988
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51181}
- Revert "[builtins] Save one word in contexts for Promise.all."
This reverts commit 7632da067b.
- Revert "[builtins] Also use the Promise#then protector for Promise#finally()."
This reverts commit d4f072ced3.
- Revert "[builtins] Don't mess with entered context for MicrotaskCallbacks."
This reverts commit 6703dacdd6.
- Revert "[debugger] Properly deal with settled promises in catch prediction."
This reverts commit 40dd065823.
- Revert "[builtins] Widen the fast-path for Promise builtins."
This reverts commit db0556b7e8.
- Revert "[builtins] Unify PerformPromiseThen and optimize it with TurboFan."
This reverts commit a582199c5e.
- Revert "[builtins] Remove obsolete PromiseBuiltinsAssembler::AppendPromiseCallback."
This reverts commit 6bf8885290.
- Revert "[builtins] Turn NewPromiseCapability into a proper builtin."
This reverts commit 313b490ddd.
- Revert "[builtins] Inline InternalPromiseThen into it's only caller"
This reverts commit f7bd6a2fd6.
- Revert "[builtins] Implement Promise#catch by really calling into Promise#then."
This reverts commit b23b098fa0.
- Revert "[promise] Remove incorrect fast path"
This reverts commit 0f6eafe855.
- Revert "[builtins] Squeeze JSPromise::result and JSPromise::reactions into a single field."
This reverts commit 8a677a2831.
- Revert "[builtins] Refactor promises to reduce GC overhead."
This reverts commit 8e7737cb58.
Tbr: hpayer@chromium.org
Bug: chromium:800651, chromium:808911, v8:5691, v8:7253
Change-Id: I8c8ea5ed32ed62f6cd8b0d027a3707ddd891e5f1
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/906991
Commit-Queue: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51158}
A version of the spec change from
https://github.com/tc39/ecma262/pull/988, but applied to the
Async-from-Sync iterator type.
This change does not modify generated bytecode (but maybe it should to
take advantage of load IC feedback for loading "next"). Doing this grows
bytecode by quite a bit, since it's necessary to throw-if-not-an-object
before loading "next" (which currently gets to live in a code stub
instead).
BUG=v8:5855
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: I0d2affef664d1069b24c54a553d62e17b49e5a16
Reviewed-on: https://chromium-review.googlesource.com/723136
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51078}
R=adamk@chromium.org
Change-Id: Ib6b66003aaf8694c1e5eed6db7d2537322eddad8
Reviewed-on: https://chromium-review.googlesource.com/897498
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51051}
A given JSPromise can either be in pending state, and accumulates
reactions, or in settled state, where all reactions are scheduled
as microtasks, and it carries a result. So we can use a single field
on the JSPromise instance to hold both the result and the reactions
and that field is interpreted differently depending on the status of
the JSPromise.
Bug: v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I19a7d499c88f452f0d35979ab95deb110021cde9
Reviewed-on: https://chromium-review.googlesource.com/895528
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51004}
This prevents unnecessary switching back and forth between internal and
public API boundaries. It is also a step towards making all WebAssembly
internals completely independent of "scheduled exception" values.
R=ahaas@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I46e8cb4fad3d255d9bd20b9c343901a03a25426c
Reviewed-on: https://chromium-review.googlesource.com/895742
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51002}
This implements the ideas outlined in the section "Microtask queue"
of the exploration document "Promise and async/await performance" (at
https://goo.gl/WHRar2), except that the microtask queue stays a linear
FixedArray for now, to avoid running into trouble with the parallel
scavenger. This way we can already save a significant amount of
allocations, thereby reducing the GC frequency quite a bit.
All items on the microtask queue are now proper structs that subclass
Microtask, i.e. we also wrap JSFunction and MicrotaskCallback jobs
into structs. We also consistently remember the context for every
microtask (except for MicrotaskCallback where we don't have a
context), and execute it later in exactly that context (as required
by the spec anyways for the Promise related jobs). Particularly
interesting is the PromiseReactionJobTask and its subclasses, since
they are designed to have the same size as the PromiseReaction. When
we resolve a JSPromise we just take the existing PromiseReaction
instances and morph them into PromiseFulfillReactionJobTask or
PromiseRejectReactionJobTask (depending whether you "Fulfill" or
"Reject"). That way the JSPromise class is now only 6 words instead
of 10 words.
Also the PromiseReaction and the reaction tasks can either carry a
JSPromise (for the fast native case) or a PromiseCapability (for the
generic case), which means we don't always pay the overhead of having
to also remember the "deferred resolve" and "deferred reject" handlers
that are only relevant for the generic case anyways.
It also fixes a spec violation where we called "then" before we actually
enqueued the PromiseResolveThenableJob, which is observably wrong.
Calling it later has the advantage that it should be fairly
straight-forward now to completely avoid it for native Promise
instances.
This seems to save around 10-20% on the various Promise benchmarks and
micro-benchmarks. We expect to gain even more as we're now able to
inline various operations into TurboFan optimized code easily.
Bug: v8:7253
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I893d24ca5bb046974b4f5826a8f6dd22f1210b6a
Reviewed-on: https://chromium-review.googlesource.com/892819
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50980}
Async generators didn't correctly handle the situation where one calls
.return on a suspended-at-start async generator and passes a
promise-like object whose awaiting causes a new request to the
generator.
Bug: chromium:805729
Change-Id: I4da13ab5bd97f8c2a2c5373242a2d5e2ab0f7f10
Reviewed-on: https://chromium-review.googlesource.com/891231
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50974}
This is a reland of 181ac2b0dc that fixes
the issue with load elimination.
Original change's description:
> [ic] Improve performance of KeyedStoreIC on literal-based arrays.
>
> In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
> used to bail out when seeing a COW array, even if the store that
> installed the handler had been operating on the very same array.
>
> This CL adds support for COW arrays to the mode (and renames it to
> STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
>
> Bug: v8:7334
> Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
> Reviewed-on: https://chromium-review.googlesource.com/876014
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50840}
TBR=bmeurer@chromium.org
Bug: v8:7334, chromium:805768
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3d9c1b08583e08d68a1d30242a25e4a2190c8c55
Reviewed-on: https://chromium-review.googlesource.com/886261
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50885}
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}
This reverts commit 181ac2b0dc.
Reason for revert: TF changes break load elimination.
Original change's description:
> [ic] Improve performance of KeyedStoreIC on literal-based arrays.
>
> In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
> used to bail out when seeing a COW array, even if the store that
> installed the handler had been operating on the very same array.
>
> This CL adds support for COW arrays to the mode (and renames it to
> STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
>
> Bug: v8:7334
> Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
> Reviewed-on: https://chromium-review.googlesource.com/876014
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50840}
TBR=neis@chromium.org,ishell@chromium.org,bmeurer@chromium.org
Change-Id: Id841d91b12d199045e0a9c4ddae2c2ead20b5e21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7334
Reviewed-on: https://chromium-review.googlesource.com/885814
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50860}
In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
used to bail out when seeing a COW array, even if the store that
installed the handler had been operating on the very same array.
This CL adds support for COW arrays to the mode (and renames it to
STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
Bug: v8:7334
Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
Reviewed-on: https://chromium-review.googlesource.com/876014
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50840}
This reverts commit 03e9d415c2.
Reason for revert: Correctness issues, see https://crbug.com/804159.
Bug: chromium:804159
Original change's description:
> Reland: Reimplement Object.entries/values as CSA to optimize performance.
>
> Add Object.entries/values builtins to debug-evaluate.cc whitelist macro.
> This fix revert commit of https://chromium-review.googlesource.com/c/v8/v8/+/859937
> Original is https://chromium-review.googlesource.com/c/v8/v8/+/810504
> >> Reimplements Object.entries/values as CSA to optimize performance. See more detail about https://bugs.chromium.org/p/v8/issues/ Issue 6804.
>
> This reverts commit 1b49f725ac.
>
> Bug: v8:6804
> Change-Id: I57e8b66e1c4ece2abb52e1630a97fbfd4070d810
> Reviewed-on: https://chromium-review.googlesource.com/860679
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50492}
TBR=yangguo@chromium.org,cbruni@chromium.org,jgruber@chromium.org,ishell@chromium.org,brn@b6n.ch
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6804
Change-Id: I39b1854ca7c2f57819ba377f84560356d3756bfb
Reviewed-on: https://chromium-review.googlesource.com/877886
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50746}
Until now, String.prototype.{trimLeft,trimRight} were non-standard
language extensions, required for Web compatibility.
The proposal at https://github.com/tc39/proposal-string-left-right-trim
standardizes this functionality as String.prototype.{trimStart,trimEnd},
and defines String.prototype.{trimLeft,trimRight} as aliases for
backwards compatibility.
This patch implements that proposal behind the --harmony-string-trimming
flag.
Bug: v8:6530
Change-Id: Id21e624c12a79e6b782efb049a48901b9da7db71
Reviewed-on: https://chromium-review.googlesource.com/867044
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50717}
This reverts commit d30a8fa9b4.
Reason for revert: no-snap test failures here
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20nosnap%20-%20debug/builds/17068
You need to update the whitelist in src/debug/debug-evaluate.cc.
I'm a bit surprised this only happens in no-snap builds.
Original change's description:
> Reimplement Object.entries/values as CSA to optimize performance.
>
> This implementation based on runtime implementation.
>
> Bug: v8:6804
> Change-Id: Ib8bfcc4648e44a999789237effc0275c5e4d9936
> Reviewed-on: https://chromium-review.googlesource.com/810504
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50477}
TBR=cbruni@chromium.org,jgruber@chromium.org,ishell@chromium.org,brn@b6n.ch
Change-Id: I1a0c8e3c054a57ca4d15f7a064ff4b28ca133b16
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6804
Reviewed-on: https://chromium-review.googlesource.com/859937
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50478}
Before this, only the [[ProxyHandler]] was set to null during revocation
of the Proxy through either the v8::Proxy::Revoke() or the
Proxy.revocable() API. To be consistent with the spec, the Proxy's
target is set to null as well. This change should not be observable
through JS, since the check for if the Proxy is revoked should always
use the handler. But the changed value is exposed through the public
v8::Proxy::GetTarget() API, which is used by the inspector API and
Node.js.
Also included is a much more comprehensive test for Inspector's support
for Proxy, which prior to this commit did not work as intended.
Bug:
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I727607ec2b3cea8642cd636573932c1e6bb5cc07
Reviewed-on: https://chromium-review.googlesource.com/854676
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50476}
We collect instance type statistics in FatalProcessOutOfMemory into an
array, which is allocated to the max instance type value. While we want
to leave space to ensure new instance types do not affect constants in
the API, we can be more frugal.
We currently serialize 350 maps into the startup/context snapshot. Even
if we assign a distinct instance type to each of these maps, we would
still have more than enough to spare with this change.
R=ulan@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3e583c2c8da3342e9132d96046b5d80cd41afd72
Reviewed-on: https://chromium-review.googlesource.com/842542
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50302}
We used to frequently break the ABI when we introduced new instance
types because some instance types are hard-coded in v8.h.
Now that we have more instance types available, we can leave some
room to anticipate future new instance types.
Also take this opportunity to reorder some instance types.
Also see: https://github.com/nodejs/node/issues/17754
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I9b59eeab9dfcdf11d779f0b700fc5dce30d3eebe
Reviewed-on: https://chromium-review.googlesource.com/833874
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50223}
... by "inlining" the Tuple2 object into the data handler.
Bug: v8:7206, v8:5561
Change-Id: I8517b2faa8d13bd16b8ec99c7ea8ab97c73a5f2a
Reviewed-on: https://chromium-review.googlesource.com/819233
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50164}
... instead of checking if the property cell is still empty when loading/storing
through JSGlobalObject prototype.
Also invalidate the validity cell when new global lexical variables appear in the
script.
Bug: v8:5561
Change-Id: Iaf122dffe76d57b32e2b69291dee079e772b271c
Reviewed-on: https://chromium-review.googlesource.com/819230
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50100}
This ensures that MigrateFastToFast does not overflow the length of the
property array.
Bug: chromium:789393
Change-Id: I77adc319c1c8c469ea482bad35ead8661d535192
Reviewed-on: https://chromium-review.googlesource.com/824167
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50086}
- Introduce explicit CallXXX helpers in PropertyCallbackArguments for
all Callback functions exposed in the api.
- Add bit on the Interceptors for checking whether they for names or
indices.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Id862e4e39ba75b4610156adfe83f3eecfb2c048f
Reviewed-on: https://chromium-review.googlesource.com/799910
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49969}
For instance, it now knows that Number(x) has type Number.
(In this particular case, we used to know that already due to
js-call-reduction of Number but that was recently disabled because
of BigInts.)
Bug: v8:6791
Change-Id: If5c57d46fc8448ca530a9ce7c9d14d63daa0f31c
Reviewed-on: https://chromium-review.googlesource.com/811264
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49909}
They will eventually be used instead of Tuple3/FixedArray by the IC system.
Bug: v8:5561, v8:7159
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I39faad1b2dc10ce7d42cb7477ea87b64d1e0b44c
Reviewed-on: https://chromium-review.googlesource.com/806178
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49908}
- When a dictionary mode prototype changes, invalidate the validity cell.
- The dictionary mode prototypes don't need to be gathered into an array in InitPrototypeChecks.
Bug: v8:7159
Change-Id: I1c7bbaf4b20556f44df18be1463d38fa4fbabe05
Reviewed-on: https://chromium-review.googlesource.com/793732
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49857}
1) Make sure we don't enable prototype setup mode for parent class and its prototype
objects.
2) Make sure we create builtins and their prototypes with completed setup mode.
3) Drive-by-fix: setup typed array classes in bootstrapper.cc instead of typedarray.js,
and drop %FunctionSetPrototype().
Bug: v8:7115, v8:5902
Change-Id: I58ac091d85647abc3307bd47baf48e378e3695c5
Reviewed-on: https://chromium-review.googlesource.com/790992
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49655}
This CL also includes fixes for CF issues found while the previous
reland was active.
Bug: v8:5799, chromium:783902, chromium:783926, chromium:783822
Change-Id: I1f7d9b037d90838469c45f5d72771a77444c662e
Reviewed-on: https://chromium-review.googlesource.com/764067
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49457}
The only empty PropertyArray is the empty_property_array object on the
isolate. Allowing empty PropertyArrays causes the turbofan to ignore the
existing hash when growing the backing store again. We currently only end
up with the empty PropertyArray when following back transitions.
Bug: chromium:781218, chromium:783713
Change-Id: If41dd09b965cdc8d957b9ca50ba3c8a7f4254769
Reviewed-on: https://chromium-review.googlesource.com/763230
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49318}
This is necessary in order to support class literals boilerplates which will
contain descriptor arrays not attached to maps.
This CL introduces Heap::descriptor_array_map() which will be used only for
descriptor arrays templates created as a part of class literal boilerplate.
We don't use the new map for all descriptors for now because in order to handle
chicken-egg problem in deserializer which can be solved in a clean and readable
way only if introduce a DESCRIPTOR_ARRAY_TYPE instance type which we can't
currently do because the InstanceType enum is already "full".
Bug: v8:5799
Change-Id: I732d236b0dda2c436ab3ce3ac5967f6c66162df3
Reviewed-on: https://chromium-review.googlesource.com/758360
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49271}
This change
- adds new maps for elements, global, and named dictionaries.
- adds support to embed these dictionaries in the startup snapshot.
- adds support to embed these dictionaries in the code cache.
- refactors the rehashing logic.
TBR=mstarzinger@chromium.org, ishell@chromium.org, jgruber@chromium.org
Bug: v8:6593
Change-Id: I2455fe2a9cc6e93247940de99de5f124c2ada137
Reviewed-on: https://chromium-review.googlesource.com/756693
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49167}
This reverts commit 3877bf6f4b.
Reason for revert: failed compilation on Win64/clang:
https://build.chromium.org/p/client.v8/builders/V8%20Win64%20-%20clang/builds/9015
Original change's description:
> Snapshot: support rehashing property and element dictionaries.
>
> This change
> - adds new maps for elements, global, and named dictionaries.
> - adds support to embed these dictionaries in the startup snapshot.
> - adds support to embed these dictionaries in the code cache.
> - refactors the rehashing logic.
>
> R=ishell@chromium.org, jgruber@chromium.org, mstarzinger@chromium.org
>
> Bug: v8:6593
> Change-Id: I8d9a7ba7145f1af4e6e15301a4d5611f07c77f33
> Reviewed-on: https://chromium-review.googlesource.com/753323
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49155}
TBR=yangguo@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org
Change-Id: I0b45d2d07da97b9a7953abf4ad24eec4ea944306
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6593
Reviewed-on: https://chromium-review.googlesource.com/755493
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49156}
This change
- adds new maps for elements, global, and named dictionaries.
- adds support to embed these dictionaries in the startup snapshot.
- adds support to embed these dictionaries in the code cache.
- refactors the rehashing logic.
R=ishell@chromium.org, jgruber@chromium.org, mstarzinger@chromium.org
Bug: v8:6593
Change-Id: I8d9a7ba7145f1af4e6e15301a4d5611f07c77f33
Reviewed-on: https://chromium-review.googlesource.com/753323
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49155}
This adds support to the KeyedLoadIC to ignore out of bounds accesses
for Strings and return undefined instead. We add a dedicated bit to the
Smi handler to encode the OOB state and have TurboFan generate appropriate
code for that case as well. This is mostly useful when programs
accidentially access past the length of a string, which was observed and
fixed for example in Babel recently, see
https://github.com/babel/babel/pull/6589
for details. The idea is to also extend this mechanism to Arrays and
maybe other receivers, as reading beyond the length is also often used
in jQuery and other popular libraries.
Note that this is considered a mitigation for a performance cliff and
not a general optimization of OOB accesses. These should still be
avoided and handled properly instead.
This seems to further improve the babel test on the web-tooling-benchmark
by around 1%, because the OOB access no longer turns the otherwise
MONOMORPHIC access into MEGAMORPHIC state.
Bug: v8:6936, v8:7014
Change-Id: I9df03304e056d7001a65da8e9621119f8e9bb55b
Reviewed-on: https://chromium-review.googlesource.com/744022
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49049}
Rename |property_attributes| to |initial_property_attributes| and ensure
that it is used as a storage of values only for AccessorInfos installed in
API Templates (i.e. ObjectTemplate and FunctionTemplate).
When an AccessorInfo is installed directly into an existing JS object
(via JSObject::SetAccessor) or into a DescriptorArray (when certain V8
objects' shapes are configured) it is not necessary to thread attributes
being set through the AccessorInfo instance.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ibe61026f08c42549756f694129a286635ffe5769
Reviewed-on: https://chromium-review.googlesource.com/730425
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48978}
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}
Have JSProxy and JSGlobalProxy use the properties or hash technology
like we use for all other JSReceivers. Also unify and simplify the
code dealing with these hashes.
Bug: v8:6344, v8:6911
Change-Id: Ic995639c74211ba6f33acd73428b8c6d95bf7919
Reviewed-on: https://chromium-review.googlesource.com/737833
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48930}
This is a reland of eeaffa9f33
Original change's description:
> [objects] Introduce {CodeDataContainer} object type.
>
> This introduces the {CodeDataContainer} as a container for all mutable
> fields associated with a {Code} object. For now only the kind-specific
> flags are moved, but more fields can/will be moved gradually. The goal
> is to make all fields in the {Code} header be immutable eventually.
>
> R=jarin@chromium.org
> BUG=v8:6792
>
> Change-Id: I2eeba893afaba877fb6117e1f18371898c3a175e
> Reviewed-on: https://chromium-review.googlesource.com/732987
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48902}
Bug: v8:6792
Change-Id: I31a127df4bb8ee5fedb4d73755df4deae6e1d352
Reviewed-on: https://chromium-review.googlesource.com/738109
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48928}
This reverts commit eeaffa9f33.
Reason for revert: Breaks msan compile (uninitialized value in snapshot):
https://build.chromium.org/p/client.v8/builders/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/builds/17824
Original change's description:
> [objects] Introduce {CodeDataContainer} object type.
>
> This introduces the {CodeDataContainer} as a container for all mutable
> fields associated with a {Code} object. For now only the kind-specific
> flags are moved, but more fields can/will be moved gradually. The goal
> is to make all fields in the {Code} header be immutable eventually.
>
> R=jarin@chromium.org
> BUG=v8:6792
>
> Change-Id: I2eeba893afaba877fb6117e1f18371898c3a175e
> Reviewed-on: https://chromium-review.googlesource.com/732987
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48902}
TBR=mstarzinger@chromium.org,jarin@chromium.org
Change-Id: I74fe833b074752d640cff4aa4680f250e1bd8780
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6792
Reviewed-on: https://chromium-review.googlesource.com/738029
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48904}
This introduces the {CodeDataContainer} as a container for all mutable
fields associated with a {Code} object. For now only the kind-specific
flags are moved, but more fields can/will be moved gradually. The goal
is to make all fields in the {Code} header be immutable eventually.
R=jarin@chromium.org
BUG=v8:6792
Change-Id: I2eeba893afaba877fb6117e1f18371898c3a175e
Reviewed-on: https://chromium-review.googlesource.com/732987
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48902}
... mainly by adapting Object::Compare and
CodeStubAssembler::RelationalComparison.
TBR=rmcilroy@chromium.org
Change-Id: I34448d45b4950b9318263c4a667aa9db7d77232d
Bug: v8:6791
Reviewed-on: https://chromium-review.googlesource.com/730730
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48873}
HTMLCollection and NodeList have InstanceType
JS_SPECIAL_API_OBJECT_TYPE, and therefore always run the slow case
of GetAlignedPropertyFromInternalField. This slows down the performance
of indexedPropertyGetter for both types, which are very commonly used
in websites.
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I36bd2cd7d9bbc19149e15174f6868b8a1f1658c8
Reviewed-on: https://chromium-review.googlesource.com/726529
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Adithya Srinivasan <adithyas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48760}
A followup CL will move feedback slot allocation to the bytecode generator,
which means it won't be done for asm_wasm code and the function will have an
incorrect vector spec. Since asm_wasm doesn't use a feedback vector, just
prevent it from being allocated for this code.
BUG=v8:6921
Change-Id: I65a06f60bd75b54e5ef0df323184aad841e26177
Reviewed-on: https://chromium-review.googlesource.com/725703
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48692}
Now that {DeoptimizationOutputData} does not exists anymore we can
rename {DeoptimizationInputData} to just {DeoptimizationData}.
R=jarin@chromium.org
Change-Id: Ib67967539d33714cc15e5d5b6dde522a9ede64b2
Reviewed-on: https://chromium-review.googlesource.com/725349
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48684}
This CL fixes all occurences that don't require special OWNER reviews,
or can be reviewed by Michi.
After this one, we should be able to reenable the readability/check
cpplint check.
R=mstarzinger@chromium.org
Bug: v8:6837, v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic81d68d5534eaa795b7197fed5c41ed158361d62
Reviewed-on: https://chromium-review.googlesource.com/721120
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48670}
New code should use nullptr instead of NULL.
This patch updates existing use of NULL to nullptr where applicable,
making the code base more consistent.
BUG=v8:6928,v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: I4687f5b96fcfd88b41fa970a2b937b4f6538777c
Reviewed-on: https://chromium-review.googlesource.com/718338
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48557}
There was a helpful TODO telling where it should live.
BUG=v8:5402,v8:6921
Change-Id: Id9022c72c9e7de8d76ea0db964217b766299195d
Reviewed-on: https://chromium-review.googlesource.com/718337
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48524}
This is a reland of 3d023952f2
Original change's description:
> [runtime] Make JSFunction::prototype_or_initial_map field optional.
>
> Functions that don't have prototype need to store neither prototype nor
> initial map, so the |prototype_or_initial_map| field is not required for
> such maps.
>
> Bug: v8:6459
> Change-Id: I4b3066bd6a4fed42c19f217bae82a8bce552bdca
> Reviewed-on: https://chromium-review.googlesource.com/570250
> Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Igor Sheludko <ishell@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#46840}
Bug: v8:6459
Change-Id: I54e3516ea70474c6d4f873f7b91e74cb8a7d622a
Reviewed-on: https://chromium-review.googlesource.com/583307
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48523}
In the current implementation of hash code for objects (identity hash),
we do not bother to shift the hash when we retrieve it from the
hash-length bitfield in a property array. (Even worse, we store shifted
value even if we do not have property array or inside dictionaries.)
That means that the hash-code for objects is always divisible by 1024.
Since our hash table uses a simple masking with (2^logsize - 1) to
obtain the bucket, we get terrible hash collisions - essentially, our
hash table degenerates to a linked list for fewer than 1024 elements.
This CL always shifts the hash code so that the value in the lowest
21 bits is uniformly distributed.
This results in big improvements on medium to large hash tables.
A program storing 1M elements into a WeakMap gets roughly
17x faster. A program retrieving 1M elements from a Map
improves even more dramatically (>100x).
const a = [];
for (let i = 0; i < 1e6; i++) a[i] = {};
const m = new Map();
console.time("Map.set");
for (let i = 0; i < 1e6; i++) {
m.set(a[i], i);
}
console.timeEnd("Map.set");
console.time("Map.get");
let s = 0;
for (let i = 0; i < 1e6; i++) {
s += m.get(a[i]);
}
console.timeEnd("Map.get");
const w = new WeakMap();
console.time("WeakMap.set");
for (let i = 0; i < 1e6; i++) {
w.set(a[i], i);
}
console.timeEnd("WeakMap.set");
Before the fix:
Map.set: 157.575000
Map.get: 28333.182000
WeakMap.set: 6923.826000
After the fix:
Map.set: 178.382000
Map.get: 185.930000
WeakMap.set: 409.529000
Note that Map does not suffer from the hash collision on insertion because
it uses chaining (insertion into linked list is fast regardless of size!), and
we cleverly avoid lookup in the hash table on update if the key does not have
identity hash yet. This is in contrast to the WeakMap, which uses
open-addressing, and deals with collisions on insertion.
Bug: v8:6916
Change-Id: Ic5497bd4501e3b767b3f4acb7efb4784cbb3a2e4
Reviewed-on: https://chromium-review.googlesource.com/713616
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48480}
This introduces a ToNumeric conversion to the runtime and interpreter.
ToNumeric behaves like ToNumber, except that it also lets BigInts pass.
Bug: v8:6791
Change-Id: Idf9d0b5d283638459fe5893de41cc120356247a7
Reviewed-on: https://chromium-review.googlesource.com/707013
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48440}
This allows us to remove the loop while calculating the hash value and
just use the HashMask as the mask for ComputeIntegerHash. This
previously overflowed on 32-bit systems failing the Smi::IsValid
check.
Bug: v8:6404
Change-Id: I84610a7592fa9d7ce4fa5cef7903bd50b8e8a4df
Reviewed-on: https://chromium-review.googlesource.com/702675
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48319}
This CL speeds up a common pattern found in the React framework:
function f(a, b, c) { ... };
let f_bound = f.bind(this, 1);
let f_bound2 = f_bound(this, 2);
This CL yields roughly a 15x improvement for rebinding a bound function.
Change-Id: I4d8580a5bce422af411148bc6b3e4eb287fac9ce
Reviewed-on: https://chromium-review.googlesource.com/695206
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48283}
Good thing this class is actually being unused. Vector<T> is iterable,
so it should just be iterated using a foreach loop.
R=mstarzinger@chromium.org
Change-Id: Ieb6729e5b1336888989d5ec6128b0782b158b1f7
Reviewed-on: https://chromium-review.googlesource.com/695525
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48279}
The Object.is builtin provides an entry point to the abstract operation
SameValue, which properly distinguishes -0 and 0, and also identifies
NaNs. Most of the time you don't need these, but rather just regular
strict equality, but when you do, Object.is(o, -0) is the most readable
way to check for minus zero.
This is for example used in Node.js by formatNumber to properly print -0
for negative zero. However since the builtin thus far implemented as C++
builtin and TurboFan didn't know anything about it, Node.js considering
to go with a more performant, less readable version (which also makes
assumptions about the input value) in
https://github.com/nodejs/node/pull/15726
until the performance of Object.is will be on par (so hopefully we can
go back to Object.is in Node 9).
This CL ports the baseline implementation of Object.is to CSA, which
is pretty straight-forward since SameValue is already available in
CodeStubAssembler, and inlines a few interesting cases into TurboFan,
i.e. comparing same SSA node, and checking for -0 and NaN explicitly.
On the micro-benchmarks we go from
testNumberIsMinusZero: 1000 ms.
testObjectIsMinusZero: 929 ms.
testObjectIsNaN: 954 ms.
testObjectIsSame: 793 ms.
testStrictEqualSame: 104 ms.
to
testNumberIsMinusZero: 89 ms.
testObjectIsMinusZero: 88 ms.
testObjectIsNaN: 88 ms.
testObjectIsSame: 86 ms.
testStrictEqualSame: 105 ms.
which is a nice 10x to 11x improvement and brings Object.is on par with
strict equality for most cases.
Drive-by-fix: Also refactor and optimize the SameValue check in the
CodeStubAssembler to avoid code bloat (by not inlining StrictEqual
into every user of SameValue, and also avoiding useless checks).
Bug: v8:6882
Change-Id: Ibffd8c36511f219fcce0d89ed4e1073f5d6c6344
Reviewed-on: https://chromium-review.googlesource.com/700254
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48275}
The TypedArray.prototype[Symbol.toStringTag] getter is currently the best (and
as far as I can tell only definitely side-effect free) way to check whether an
arbitrary object is a TypedArray - either generally TypedArray or a specific
one like Uint8Array. Using the getter is thus emerging as the general pattern
to detect TypedArrays, even Node.js now adapted it starting with
https://github.com/nodejs/node/pull/15663
for the isTypedArray and isUint8Array type checks in lib/internal/util/types.js
now.
The getter returns either the string with the TypedArray subclass name
(i.e. "Uint8Array") or undefined if the receiver is not a TypedArray.
This can be implemented with a simple elements kind dispatch, instead of
checking the instance type and then loading the class name from the
constructor, which requires a loop walking up the transition tree. This
CL ports the builtin to CSA and TurboFan, and changes the logic to a
simple elements kind check. On the micro-benchmark mentioned in the
referenced bug, the time goes from
testIsArrayBufferView: 565 ms.
testIsTypedArray: 2403 ms.
testIsUint8Array: 3847 ms.
to
testIsArrayBufferView: 566 ms.
testIsTypedArray: 965 ms.
testIsUint8Array: 965 ms.
which presents an up to 4x improvement.
Bug: v8:6874
Change-Id: I9c330b4529d9631df2f052acf023c6a4fae69611
Reviewed-on: https://chromium-review.googlesource.com/695021
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48254}
This improves performance of ArrayBuffer.isView by roughly 2.5x itself,
and enables optimizations across ArrayBuffer.isView calls, i.e. map
checks can be eliminated across. This was discovered in a related Node
pull request (https://github.com/nodejs/node/pull/15663).
Bug: v8:6868
Change-Id: I1d56ec385f8daa0e1d44d3bc4d6c9a5558ba4522
Reviewed-on: https://chromium-review.googlesource.com/691660
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48247}
And some refactoring to the existing code for LiveEdit.
R=jarin@chromium.org
Change-Id: Ic1d626db9722b39cbcd83bf6878fc24d6094e612
Reviewed-on: https://chromium-review.googlesource.com/687014
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48233}
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}
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}
The serializer performs two passes over the code. The first pass copies out the
code content verbatim, the second pass visits references recorded in the reloc
info.
So far the first pass is implicit and happens as part of the second pass, when
we encounter a non-HeapObject reference when iterating the code object. That
however does not work for internal references. So we hit an assertion if the
first non-HeapObject reference we see is an internal reference.
This change explicitly triggers the first pass.
R=petermarshall@chromium.org
Bug: v8:6817
Change-Id: I1ee9949e10b7d9409986da83be22ac6287785f9f
Reviewed-on: https://chromium-review.googlesource.com/663867
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48010}
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}
Since we don't have a full-codegen compiler anymore, we no longer
generate Code::FUNCTION kind. Nice! Here is some cleanup.
Bug: v8:6409
Change-Id: I05634e4ca85c4037b49a4346f4e8bae8042b8762
Reviewed-on: https://chromium-review.googlesource.com/657817
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47951}
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}
Given that we no longer need to iterate over lists of optimized JS functions
(c.f. https://chromium-review.googlesource.com/c/v8/v8/+/647596), we can
remove this field. Thus saving the size of one pointer per function.
Bug: v8:6637
Change-Id: If77951f2eddba33ba350fa9ddf03a4edb3f7c7d8
Reviewed-on: https://chromium-review.googlesource.com/652373
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Juliana Patricia Vicente Franco <jupvfranco@google.com>
Cr-Commit-Position: refs/heads/master@{#47875}
Use int instead of byte to store the source position when computing a
location based on the stack trace stored in an error object.
Also add tests, since this code path was not covered before (not even
for small position where it would have succeeded).
Also, add some comments about which positions are 0-based and 1-based.
R=titzer@chromium.org
Change-Id: I313dcd6c47b77093ced9bb687415715d04eafb97
Reviewed-on: https://chromium-review.googlesource.com/645527
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47739}
Use the DEFINE_FIELD_OFFSET_CONSTANTS macro to define the fields in the
BytecodeArray layout description.
Change-Id: I89ff2d7cd967aa1a503cbedd5d95dcd80f4d038c
Reviewed-on: https://chromium-review.googlesource.com/643130
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47713}
Lazy deserialization needs to determine the underlying builtin by looking at
the SharedFunctionInfo.
This packs the builtin_id into the SFI::function_data field, and adds
convenience functions to Code as a drive-by addition.
Bug: v8:6624
Change-Id: I59093815aa6937342302153ebc95dd60edb0064e
Reviewed-on: https://chromium-review.googlesource.com/641490
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47712}
Introduce a proper empty_descriptor_array, which has the proper layout
(length is 2 and the two fields are set properly). Also add a special
EnumCache class and a matching empty_enum_cache. The contract now is
that we only need to check the EnumLength on the map to know whether we
are allowed to use the enum cache. This greatly simplifies the handling
of the enum cache (and also the descriptor arrays), especially for the
future work on optimizing keyed access via the enum cache indices.
Bug: v8:6702
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5ef517a3041163cd65ef003f691139ea52233e83
Reviewed-on: https://chromium-review.googlesource.com/641030
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47697}
Instead of using a word to store the status of the promise, this
patch uses 2 bit on flags.
Bug: v8:5046
Change-Id: Ic651338230dbe1704c68de8652676f236a3298f0
Reviewed-on: https://chromium-review.googlesource.com/634623
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47628}
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}
The initialization code of all modules must have been run
before running any module's main code. This should have been
fixed quite a while ago as part of another CL but somehow
wasn't.
In the process of fixing it now, I'm also moving the initialization
phase out of Evaluate into Instantiatiate. This corresponds more
closely to the specification and avoids confusion.
Bug: v8:1569
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I3ea5d6be0f5d371e6a4c641778c51762f1867dc8
Reviewed-on: https://chromium-review.googlesource.com/620653
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47537}
