This CL changes {CreateApiFunction} to take an explicit native context
to set on the newly created JSFunction. The CL also adds a new variant
of {ApiNatives::InstatiateFunction}, that takes a native context and passes
it through to {CreateApiFunction}.
This is a refactoring in preparation for a bugfix.
AccessorPairs can be instantiated lazily. At the time of
lazy instantiation, the current context does not necessarily match
the creation context of the holder of an AccessorPair.
Bug: chromium:986063, chromium:989909
Change-Id: Idea4b5052f2baff5c3d916f5ab8ed5017b60699b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1735308
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63063}
Building cctest has linking error when gn's args has "is_component_build = true".
This CL make the visibility of "MemOperand" and "UseScratchRegisterScope" from
"hidden" to "default" to solve this problem.
Change-Id: I3ebfaa25d598b4f2d626861b947c93d111d95456
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731213
Auto-Submit: Mu Tao <pamilty@gmail.com>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63062}
Increasing the number of scavenging tasks in the previous CL
https://chromium-review.googlesource.com/c/v8/v8/+/1697245
has helped with GC performance but increased memory usage.
This CL ensures that there are at least two scavenging tasks if the
new space size is larger than one MB.
Bug: chromium:982663,chromium:985731
Change-Id: I6edff8b90beb2740a5b75a51cf25f48aa5442482
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733074
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63060}
When the --initial-heap-size flag is set V8's heap will grow to that
value without full GCs. Additionally, full GCs will be skipped
if the heap size drops below that value.
This patch also adds a comment for the initial_heap_size_in_bytes
parameter of ResourceConstraints:ConfigureDefaultsFromHeapSize
Change-Id: I85fda14bc6422af7bf2193d530efbc9b0bd0553d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728622
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63054}
Also add a IsExtreme(double) overload.
This wasn't causing issues because there was no codepath
which exercised it (only approx operations did).
Change-Id: If7583fb567137c428d16c0d2cdfc37e086f7f3fd
Bug: v8:8460
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726675
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63053}
For variable proxies in a function inside an eval scope that point to
a dynamic variable in the eval scope, the current scope resolution will
find this variable only when the function is eagerly compiled, as the
eval scope only exists during top-level eval compilation. This causes
a mismatch between lazy- and eager- compiled functions.
With this patch, we skip these dynamic variables during lookup, so that
the lookup for the variable proxy always finds a kDynamicLocal or
kDynamicGlobal, both when compiled lazily and eagerly. This is a minor
pessimisation of performance (as we know that the lookup has to be
dynamic), but unblocks other improvements which require idempotent
bytecode generation (such as lazy source positions).
Note that the alternative, of simply not tracking dynamic variables on
the eval scope at all, is not viable due to needing this information
during conflict detection.
Bug: v8:8510
Bug: v8:9511
Change-Id: Ifa72ec05e9a97b7be418912340081b9656765fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733077
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63051}
MIPS64 has a user space of 2^40 bytes on most processors, address
space limits needs to be smaller. 256G is ok, but it will cause
many wasm tests get a OOM error.
This patch also skip some tests which need correct IEEE-745 2008
NaN bit patterns on mips.
Change-Id: I52968df3934e8748b2c42a0abf19db1540441d2b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1712929
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Yu Yin <xwafish@gmail.com>
Cr-Commit-Position: refs/heads/master@{#63050}
This makes sure the "parameters" and "results" properties of the passed
FunctionType object can be arbitrary iterable objects, not just plain
JavaScript arrays.
R=clemensh@chromium.org
TEST=mjsunit/wasm/type-reflection
BUG=v8:7742
Change-Id: Icba18c418e549deba9fff1855be4956813b1a953
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733071
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63049}
This CL adds regression tests for two bugs where the wrong native
context is used when lazy accessors are instantiated.
The first bug injects an object created in context 1, into another
context 2. The object has an accessor pair installed via
FunctionTemplate. In context 2, the property descriptor of this
accessor is retrieved, causing the JSFunction to be instantiated
with the current context (context 2) instead of the creation
context of the object (context 1).
The second bug is similar. When breakpoints are set, the whole heap
is walked and all lazy accessor pairs are instantiated. This again
uses the current context instead of using the context from which
a AccessorPair originates.
Bug: chromium:986063, chromium:989909
Change-Id: Iaaea6e81f1b9f6b55fc7583b260aa9aea035a8d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730999
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63048}
It's too slow and flakes on "V8 Linux - full debug"
Change-Id: I2a83a7a2de6a3865d230edb847a658b1b8b23bec
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733076
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63047}
JSBoundFunctionRef::serialized() and JSFunctionRef::serialized() should
tolerate being called when the heap broker is disabled, because these
methods are now called in the JSCallReducer (in order to log whether
information was missing at serialization time).
Bug: v8:7790
Change-Id: Iac8e68178422bd9bb4ebe2acb412ff42ac87cf4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733075
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63045}
Previously we were also taking into account the machine type
Change-Id: Ic76aad578f00ef24cf17b349d94cdade8f9ee29d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733072
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63044}
This is a reland of f5611402f7
Original change's description:
> [ptr-compr][arm64] Temporarily enable pointer compression on arm64
>
> ... and make sure that the arm64 ptr-compr bots proceed testing V8 without
> pointer compression in order to keep testing the other config.
>
> Commented out the 'extra' variant since it was crashing. Opened a bug
> regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
>
> Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
>
> Bug: v8:7703
> Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
> Reviewed-by: Tamer Tas <tmrts@chromium.org>
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63019}
Cq-Include-Trybots: luci.v8.try:v8_android_arm64_n5x_rel_ng
Bug: v8:7703
Change-Id: I1a82b87bf6db4e6d100aeffc29dae60ba73d8119
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730998
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63043}
Trying to use double_registers for fetching single precision fp values creates
four different implementations of this method depending on the architecture, hence
separating them out into their respective folder.
Change-Id: Ide61fe2e7a95bd8427b377959b262633d8c57e61
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730663
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Milad Farazmand <miladfar@ca.ibm.com>
Commit-Queue: Milad Farazmand <miladfar@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#63042}
This is a reland of bc33f5aeba
Contributed by titzer@chromium.org
Original change's description:
> [arraybuffer] Rearchitect backing store ownership
>
> This CL completely rearchitects the ownership of array buffer backing stores,
> consolidating ownership into a {BackingStore} C++ object that is tracked
> throughout V8 using unique_ptr and shared_ptr where appropriate.
>
> Overall, lifetime management is simpler and more explicit. The numerous
> ways that array buffers were initialized have been streamlined to one
> Attach() method on JSArrayBuffer. The array buffer tracker in the
> GC implementation now manages std::shared_ptr<BackingStore> pointers,
> and the construction and destruction of the BackingStore object itself
> handles the underlying page or embedder-allocated memory.
>
> The embedder API remains unchanged for now. We use the
> v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> keep the backing store alive properly, even in the case of aliases
> from live heap objects. Thus the embedder has a lower chance of making
> a mistake. Long-term, we should move the embedder to a model where they
> manage backing stores using shared_ptr to an opaque backing store object.
TBR=yangguo@chromium.org
BUG=v8:9380,v8:9221,chromium:986318
Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63041}
During date parsing, a FixedArray is allocated to store intermediate values,
which is slow. This CL holds the values on stack instead to save time.
This increases the score of JetStream2 Date-format-tofte-SP case by ~2%
on WhiskeyLake Chromebook.
Contributed by hao.a.xu@intel.com
Change-Id: I0d7a20a3ad9c57e3a225fff03efc2e434b20fbbc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726744
Commit-Queue: Shiyu Zhang <shiyu.zhang@intel.com>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63039}
Before this change, the tagged pointer that was loaded was not decompressed.
This makes LoadTaggedPointerFromInstance match the x64 implementation.
Bug: v8:9568
Change-Id: I8fd6d3e8dd13514ae3ef423d1c417f72e1396e4a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730993
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63038}
Previously when creating a new generic struct, one had to explicitly provide all type arguments, e.g., for the generic struct
struct Box<T: type> {
const value: T;
}
one would initialize a new box using
const aSmi: Smi = ...;
const box = Box<Smi> { value: aSmi };
With the additions in this CL the explicit type argument can be omitted. Type inference proceeds analogously to specialization of generic callables.
Additionally, this CL slightly refactors class and struct initialization, and make type inference more permissive in the presence of unsupported type constructors (concretely, union types and function types).
R=jgruber@chromium.org, tebbi@chromium.org
Change-Id: I529be5831a85d317d8caa6cb3a0ce398ad578c86
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728617
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63036}
The mode without write barriers works only if incremental marking
is disabled and the single generation mode is enabled.
Bug: v8:9533
Change-Id: Iecf83b0810f757c9b50e7fb338a2905af938f1d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1716471
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63033}
When the flag is on and some of the functions don't have bytecode,
we should gracefully print "no bytecode" instead of crashing.
Bug: chromium:983267
Change-Id: Id4e3385cd871a2dd5bead38c29a41b38319cc8d3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731003
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63031}
On Linux, both APIs uses {madvise} (and {SetPermissions} additionally
does an {mprotect}), on windows they use different APIs. It turns out that
{SetPermissions} with {kNoAccess} uses {VirtualFree} with
{MEM_DECOMMIT}, so the pages will only be "reserved" afterwards.
{DiscardSystemPages} on the other hand uses the {DiscardVirtualMemory}
which tells the OS that the content of that memory can be discarded,
but the pages stay "committed".
Thus {SetPermissions} with {kNoAccess} frees significantly more memory
than using {DiscardSystemPages}.
R=mstarzinger@chromium.org
Bug: v8:8217
Change-Id: I3555462a9c692f15ecb3eca7834eb181617d9ef9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730992
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63029}
This CL adds new ProcessedFeedback subclasses, corresponding to various IC
types:
* ForIn
* Comparison ops
* Binary/Unary ops
* InstanceOf
* Calls
The feedback is gathered at serialization time and used in several places,
namely:
* Bytecode graph building,
* and its helper class JSTypeHintLowering (with its "early lowering")
* Native context specialization
* JSCallReducer
Design doc: https://docs.google.com/document/d/1JLG0VFV8xmsAIJexU19xzlbNyP51ONqfo_Gf_2DcPC8/edit?usp=sharing
Bug: v8:7790
Change-Id: I53c3d7a17f844384f38c4ee0f0b082c114217a02
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1710663
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63028}
From JSNativeContextSpecialization::ReduceKeyedLoadFromHeapConstant
to JSNativeContextSpecialization::ReduceElementLoadFromHeapConstant.
Change-Id: Ib07a6a4bd599dc71a9a100b2f1f6baef68acbe0b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728618
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63027}
now that we are shipping this by default, we can remove the flag.
Change-Id: I298691df3eec934a5add1aa2a2748a0f3a884ab6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726452
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63026}
The unittest for {WasmCodeManager} currently disables implicit
allocations for win64 unwind info, but still deals with the implicitly
allocated jump table. With the addition of a far jump table, this logic
would get even more complex.
Thus this CL introduces a testing flag on the {WasmCodeManager} to
disable all implicit allocations, and uses that instead in the
{WasmCodeManagerTest}.
R=mstarzinger@chromium.org
Bug: v8:9477
Change-Id: I45e4bc6b9fec6d7286bf6b45f778681ae0dba746
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1725622
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63025}
This reverts commit 159df2488c.
Reason for revert: Breaks large-classes-properties test (https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8906338563361079200/+/steps/Bisect_159df248/0/steps/Retry_-_isolates/0/logs/large-classes-properties/0)
Original change's description:
> [ic] Don't transition to premonomorphic state
>
> We used to use premonomorphic state to delay initializing the ICs.
> This optimization was to avoid the cost of setting up handlers if the
> code executed only once. With lazy feedback allocation we no longer
> need this.
>
> This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
> StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
> runtime in the uninitialized state and use the builtin when there
> is no feedback.
>
>
> Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
> Commit-Queue: Mythri Alle <mythria@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63020}
TBR=mythria@chromium.org,verwaest@chromium.org
Change-Id: I4fad4e8b881d4a3f8d12149e1797b217a317eaee
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1730995
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63023}
This removes the explicit {kCallWithCallerSavedRegisters} opcode which
is just a regular call node with special handling for saving/restoring
caller saved registers before/after the call. This is now handled via
the {CallDescriptor::kCallerSavedRegisters} flag.
R=neis@chromium.org
BUG=v8:9396
Change-Id: Ie6421085eb2be8a067040222cd5215a9b1013048
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1728611
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63021}
We used to use premonomorphic state to delay initializing the ICs.
This optimization was to avoid the cost of setting up handlers if the
code executed only once. With lazy feedback allocation we no longer
need this.
This cl also renames LoadIC_Uninitialized to LoadIC_Nofeedback and
StoreIC_Uninitialized to StoreIC_Nofeedback since we now miss to
runtime in the uninitialized state and use the builtin when there
is no feedback.
Change-Id: I1633e61ea74664da51348e362c34c47a017a264a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1683525
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63020}
... and make sure that the arm64 ptr-compr bots proceed testing V8 without
pointer compression in order to keep testing the other config.
Commented out the 'extra' variant since it was crashing. Opened a bug
regarding that: https://bugs.chromium.org/p/v8/issues/detail?id=9568
Similar to x64's https://chromium-review.googlesource.com/c/v8/v8/+/1607654
Bug: v8:7703
Change-Id: Ifd46b029bab34524f9f536dcdbd1574f2ddcbf37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724216
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63019}
The mask should cover the sign (1 bit), exponent (11 bits) and quiet bit (1 bit) of significand, total of 13 bits. The old mask only covered 9 bits.
Change-Id: I6ec402b4cec34978eac8fa3e5452ad22540a93ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1726984
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63015}
Instead of having fast path for proxy only in Reflect.deleteProperty, it
is also in delete operator.
Bug: v8:6664
Change-Id: I3db919953e31f51a5dc4a504062bd691a6e17446
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717660
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63014}
