Code comments in the snapshot can now be enabled with gn
arg 'v8_enable_snapshot_code_comments'
Bug: v8:7989
Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3
Reviewed-on: https://chromium-review.googlesource.com/c/1329173
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58020}
It's possible that we encounter incorrect SP or FP values while
unwinding the stack. One reason is that third-party code like virus
protection may change the stack. If we encounter values for SP or FP
that don't make sense, we should bail out of unwinding and return false.
Bug: v8:8116, chromium:909957
Change-Id: I630fef3f619382c7035be50b86072be349ed185c
Reviewed-on: https://chromium-review.googlesource.com/c/1358514
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58018}
This reverts commit c2aaf0a6fa.
Reason for revert: Benchmarks fail, and ClusterFuzz is not happy (issue 911406, issue 911271)
Original change's description:
> [wasm][liftoff] Optimize one-armed ifs
>
> Do not implement one-armed ifs by emulating an empty else branch. In
> Liftoff, we can generate better code and save compile time by handling
> this specially. If the merge point at the end of the if is not reached
> by the if-branch, we do not need to generate any merge code.
>
> R=titzer@chromium.org
>
> Bug: v8:6600, v8:8423
> Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
> Reviewed-on: https://chromium-review.googlesource.com/c/1356508
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57968}
TBR=titzer@chromium.org,clemensh@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6600, v8:8423
Change-Id: I5cb3b069f40e34f34da4013e666f6ff293752567
Reviewed-on: https://chromium-review.googlesource.com/c/1360633
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58012}
This CL improves typed optimization more:
ChangePlainPrimitiveToNumber is only omitted if it is not required.
Change-Id: I5d81537a046c5a5a0c730fcd1e17bbdfda887687
Bug: v8:910562
Reviewed-on: https://chromium-review.googlesource.com/c/1357058
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58009}
It is possible this CL results in various regressions, the idea
is to get some data on where constant tracking helps and where
it regresses.
Bug: v8:8361
Change-Id: I2f291788a8bea03e6eaac9f51564c1da02734d1a
Reviewed-on: https://chromium-review.googlesource.com/c/1347474
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58008}
This is the first (and major) step towards converting CallApiCallback
and CallApiGetter stubs into builtins.
The CallApiCallbackStub was parameterized with the number of arguments
passed on the stack. This CL converts the compile-time parameter into
an explicit runtime parameter, and removes all uses of the stub
parameter.
Drive-by: The implementation is now mostly consistent across platforms.
Drive-by: Refactor the calling convention to free up two registers
(kCallData and kHolder are now passed on the stack).
Bug: v8:7777
Change-Id: I212dccc2930de89c264a13755918c9fae7842f1f
Reviewed-on: https://chromium-review.googlesource.com/c/1354887
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58005}
For this to work, I had to move PropertyCell out of objects.h too, since
otherwise there would be an inl include cycle which makes the code not compile.
BUG=v8:5402,v8:8238
Change-Id: I3233f86b68c1e2fd32d135fcf0bbba8101af8cb2
Reviewed-on: https://chromium-review.googlesource.com/c/1356510
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58004}
and also its pure-static subclass PrototypeUsers, whose porting
is a no-op.
Bug: v8:3770
Change-Id: I075806f784a0631058692149e71c45e455e90f73
Reviewed-on: https://chromium-review.googlesource.com/c/1355631
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58003}
to the new design.
Bug: v8:3770
Change-Id: I8483d47ac77e756395656628a80257e6462de22c
Reviewed-on: https://chromium-review.googlesource.com/c/1355630
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58002}
This is to address the first issue reported on v8:8453
Page::kPageSize is 524288
MemoryAllocator::GetCommitPageSize() returns 65536 on ppc
ObjectEndOffsetInCodePage() returns 458752
ObjectStartOffsetInCodePage() returns (65536 + 65536) => 131072
Therefore, memory = 327680, which is less than
kMaxRegularHeapObjectSize(507136), which causes the DCHECK to fail.
Bug: v8:8453
Change-Id: I6048192ded4234a6987371ec4d4b2a8553756c25
Reviewed-on: https://chromium-review.googlesource.com/c/1355422
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58001}
CPU features printout needs to use PrintF macro, in
order for the output to be in correct native encoding.
R=michael_dawson@ca.ibm.com, jyan@ca.ibm.com
Change-Id: If1762e452cdfe8c0ca954676acb20c1e60df8d2f
Reviewed-on: https://chromium-review.googlesource.com/c/1357160
Commit-Queue: Joran Siu <joransiu@ca.ibm.com>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57998}
Since all other values are not used any more if we return, we don't
need to spill anything (as might happen during {PopToRegister}).
Instead, just load the top stack value into the return register(s).
R=titzer@chromium.org
Bug: v8:6600, v8:8423
Change-Id: Ibfd02d20191459c7b136ab9a48f0cf1a53b3385d
Reviewed-on: https://chromium-review.googlesource.com/c/1358391
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57995}
Rename ParseIdentifierOrStrictReservedWord to simply ParseIdentifier and
replace the old ParseIdentifier with ParseNonRestrictedIdentifier for the
disallow_restricted_identifier case. It reuses the new ParseIdentifier.
Clients that relied on the is_strict_reserved output parameter can simply check
the token themselves.
Change-Id: I49b096d7ffbfff391483e9c18c9504e5d353e97b
Reviewed-on: https://chromium-review.googlesource.com/c/1357057
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57994}
- Rename methods,
- Introduce flags for tokens to lookup IsKeyword and IsPropertyName
- Remove "contextual keyword" leftover code.
- Inline ParsePropertyName into ParsePropertyNameOrPrivatePropertyName
since public is more likely than private.
Change-Id: Ib7633ef3c46889ecafc7a6c929029845bb8ef15c
Reviewed-on: https://chromium-review.googlesource.com/c/1357052
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57993}
If they are part of a keyed store they are pushed later using
impl()->PushPropertyName.
Change-Id: I9c104d15722dd59556c04fe3d4b0018c37d0f553
Reviewed-on: https://chromium-review.googlesource.com/c/1357055
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57991}
The register allocator spends significant amounts of time on updating
the state of active and inactive live range sets. In many cases, no
update is needed. By precomputing when the next update is due during
state management, we can avoid unnecessary checks. This cuts the time
spent for managing queues in half.
Change-Id: I44074266bed2f09171872a829f115e61608b76c8
Reviewed-on: https://chromium-review.googlesource.com/c/1352308
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Stephan Herhut <herhut@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57990}
While strictly speaking it is legal (though useless) to dynamically
create zero-length arrays with "new T[0]", UBSan does not like it,
so this CL avoids doing it. It fixes the error:
../../src/allocation.h:41:34: runtime error: constructor call on
address 0x... with insufficient space for an object of type 'unsigned char'
Bug: v8:3770
Change-Id: I5017767c59df0d8928f7493f92d2d04519083964
Reviewed-on: https://chromium-review.googlesource.com/c/1356902
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57984}
Taking kSystemPointerSize into account when determining the maximum
allowed BigInt size accidentally made the limit platform-specific.
This patch chooses a platform-independent constant (1<<30) instead.
Bug: chromium:909614
Change-Id: I4717969bc56e6dd5f1eed70b7e60e621989d0719
Reviewed-on: https://chromium-review.googlesource.com/c/1355625
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57983}
This is a reland of 10ea3f8a1d
Original change's description:
> [Compiler] Introduce IsCompiledScope which prevents flushing of compiled code
>
> Introduces a IsCompiledScope object which can be used to check whether a
> function is compiled, and ensure it remains compiled for the lifetime
> of the scope without being uncompiled by bytecode flushing. The Compile
> functions are modified to take a scope so that calling code can ensure
> the function remains compiled for the lifetime they require.
>
> Also, don't allocate a feedback vector for asm-wasm code as this
> is never used, and will be reallocated if the asm-wasm code fails to
> instantiate the module and we fallback to regular JavaScript.
>
> Also restructure Compiler::PostInstantiation() to allocate the feedback
> vector once, and do the optimized code check before optimizing for
> always opt.
>
> BUG=v8:8395
>
> Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
> Reviewed-on: https://chromium-review.googlesource.com/c/1352295
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57971}
TBR=jgruber@chromium.org,mstarzinger@chromium.org
Bug: v8:8395
Change-Id: I8dc00798a5680997990c879c3380fe4febd47297
Reviewed-on: https://chromium-review.googlesource.com/c/1357045
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57982}
to the new design.
Bug: v8:3770
Change-Id: I63291cc8eccfa1da20e84c6d3e9f48f253409396
Reviewed-on: https://chromium-review.googlesource.com/c/1355627
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57981}
This reverts commit 10ea3f8a1d.
Reason for revert: Causing failure on gc_stress bot:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8928421099411850688/+/steps/Bisect_10ea3f8a/0/steps/Retry/0/logs/collections-construct../0
Original change's description:
> [Compiler] Introduce IsCompiledScope which prevents flushing of compiled code
>
> Introduces a IsCompiledScope object which can be used to check whether a
> function is compiled, and ensure it remains compiled for the lifetime
> of the scope without being uncompiled by bytecode flushing. The Compile
> functions are modified to take a scope so that calling code can ensure
> the function remains compiled for the lifetime they require.
>
> Also, don't allocate a feedback vector for asm-wasm code as this
> is never used, and will be reallocated if the asm-wasm code fails to
> instantiate the module and we fallback to regular JavaScript.
>
> Also restructure Compiler::PostInstantiation() to allocate the feedback
> vector once, and do the optimized code check before optimizing for
> always opt.
>
> BUG=v8:8395
>
> Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
> Reviewed-on: https://chromium-review.googlesource.com/c/1352295
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57971}
TBR=rmcilroy@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org
Change-Id: I1449a02a0aceb9757440757628e586df33972a40
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8395
Reviewed-on: https://chromium-review.googlesource.com/c/1357042
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57974}
This has significant impact on validation time (11% regression, see
linked bug). These annotations bring us back to the old performance
(according to local measurements it even makes us better than before).
R=mstarzinger@chromium.org
Bug: chromium:910432
Change-Id: I8e701f9577d53115b3db22be2a09487414c965df
Reviewed-on: https://chromium-review.googlesource.com/c/1356511
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57973}
Introduces a IsCompiledScope object which can be used to check whether a
function is compiled, and ensure it remains compiled for the lifetime
of the scope without being uncompiled by bytecode flushing. The Compile
functions are modified to take a scope so that calling code can ensure
the function remains compiled for the lifetime they require.
Also, don't allocate a feedback vector for asm-wasm code as this
is never used, and will be reallocated if the asm-wasm code fails to
instantiate the module and we fallback to regular JavaScript.
Also restructure Compiler::PostInstantiation() to allocate the feedback
vector once, and do the optimized code check before optimizing for
always opt.
BUG=v8:8395
Change-Id: I3f1a71143fcae3d1a0c01eefe91ebb4b8594221a
Reviewed-on: https://chromium-review.googlesource.com/c/1352295
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57971}
Do not implement one-armed ifs by emulating an empty else branch. In
Liftoff, we can generate better code and save compile time by handling
this specially. If the merge point at the end of the if is not reached
by the if-branch, we do not need to generate any merge code.
R=titzer@chromium.org
Bug: v8:6600, v8:8423
Change-Id: Ie8ea69dd7491f225605a8e1b986d275d869aa90b
Reviewed-on: https://chromium-review.googlesource.com/c/1356508
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57968}
Termination exceptions tear down V8 to the bottom-most V8 call. If there is a
v8::TryCatch scope around that call, it returns true for HasTerminated() and
HasCaught(). However, Isolate::IsExecutionTerminating() returns false and we
can call into V8 from still inside the v8::TryCatch scope.
Changes that this patch introduces:
- You need to leave the v8::TryCatch scope around the bottom-most call to
reset the termination state, in order to resume.
- Explicitly check for termination exception and reporting it through the
DevTools protocol after Runtime.evaluate and Debugger.evaluateOnCallFrame.
Bug: v8:8455
Change-Id: I1f36f7a365985469813c2619bf16f18ee69aa4b8
Reviewed-on: https://chromium-review.googlesource.com/c/1337582
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57963}
The placement of the exceptipon section is by now restricted to be in
between the Global and the Import section. This changes our validation
to check this stricter requirement now.
R=clemensh@chromium.org
TEST=unittests/WasmModuleVerifyTest
BUG=v8:8091
Change-Id: Ib3ea625fd4df93bffda47ced09e6969159f7ac70
Reviewed-on: https://chromium-review.googlesource.com/c/1356504
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57962}
64-bit implementations of ExtractBits and InsertBits were using 32-bit
instructions. Masking when representation of instruction is 64 is now
correct.
Also added optimization for 32-bit InsertBits.
Change-Id: I3d5117835daa67708e544d01d1d9058dcc0cc64e
Reviewed-on: https://chromium-review.googlesource.com/c/1355141
Reviewed-by: Sreten Kovacevic <skovacevic@wavecomp.com>
Commit-Queue: Sreten Kovacevic <skovacevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#57961}
Building on linux x64 with "is_component_build = true" currently fails
with linker errors (undefined references). This CL fixes that.
R=ahaas@chromium.orgTBR=mseaborn@chromium.org,mark@chromium.org
Bug: v8:8532
Change-Id: I6b32c00bd974a22268ad1f161ce06a9ebe47c805
Reviewed-on: https://chromium-review.googlesource.com/c/1356505
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57960}
Move from ParseAndClassifyIdentifier to places where we either know that what
we're parsing are parameters, or where they could become (async) arrow formals.
Change-Id: Ic69bb586ed29ba9ac7b4dbef5d11a2e1954e7332
Reviewed-on: https://chromium-review.googlesource.com/c/1356503
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57957}
In the case of using start and size to manage range, the range is start
~ start + size - 1, start + size is out of the range.
The template function IsInRange(T value, U lower_limit, U higher_limit)
judge whether value is in the range lower_limit ~ higher_limit.
IsInRange(pc, start, start + isolate->embedded_blob_size()) misjudge
the case pc == start + isolate->embedded_blob_size()
Signed-off-by: Tao Pan <tao.pan@intel.com>
Change-Id: Iad172454bacb27a1328bbdda5863d28c9853a6db
Bug: v8:8530
Change-Id: Iad172454bacb27a1328bbdda5863d28c9853a6db
Reviewed-on: https://chromium-review.googlesource.com/c/1355633
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tao Pan <tao.pan@intel.com>
Cr-Commit-Position: refs/heads/master@{#57955}
This is a reland of 9436e8a817
This CL simplifies the wasm/futex.js test so that it doesn't push the
limits of d8.
Original change's description:
> [wasm] Add I64AtomicWait implementation
>
> Bug=v8:8075
> R=adamk@chromium.org,binji@chromium.org
>
> Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
> Reviewed-on: https://chromium-review.googlesource.com/c/1342948
> Reviewed-by: Adam Klein <adamk@chromium.org>
> Reviewed-by: Ben Smith <binji@chromium.org>
> Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57917}
Change-Id: Ifd26f1ecdb9fe24a1896162bb4d4285f9188a9ba
Reviewed-on: https://chromium-review.googlesource.com/c/1351304
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57953}
Bug: v8:3770
Change-Id: I6ad84a663926fffc9e1acc590c13780c39461274
Reviewed-on: https://chromium-review.googlesource.com/c/1351248
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57952}
The bulk-memory proposal adds a new DataCount section that declares the
number of data segments that are expected to be seen in the Data
section. This is similar to the way the number of functions is split
between the Function and Code sections.
The DataCount section occurs before the Code section, so we can do
single-pass validation of the new `memory.init` and `memory.drop`
instructions, which have data segment indices as immediates.
Bug: v8:7747
Change-Id: Ibc5a7ee9336dbc5d0fd667572c42cb065c048e00
Reviewed-on: https://chromium-review.googlesource.com/c/1352792
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57951}
This should reduce the likelyhood of getting indistinguishable map log
events with --trace-maps.
Bug: v8:8524
Change-Id: I5dad7a026ec9384960177298afadc1f9fa710eda
Reviewed-on: https://chromium-review.googlesource.com/c/1354890
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57950}
Make sure to check that the number of declared functions (specified in the
function section) matches the number of function bodies, even if the code
section is omitted.
Note that it is valid to have a function section with zero declared functions
and an omitted code section, and vice versa.
Bug: v8:8514
Change-Id: I4effa5abe2ed6d71146a665d2df6a2f48b5a84be
Reviewed-on: https://chromium-review.googlesource.com/c/1351306
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57949}
This CL moves a number of memory-related methods out of utils into its
own header, since utils.h is included in many places that do not need
these methods.
R=clemensh@chromium.org,mstarzinger@chromium.org
Change-Id: I5155baf329844784286413408c05c7108b789020
Reviewed-on: https://chromium-review.googlesource.com/c/1354889
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57948}
The problem were missing V8_EXPORT_PRIVATE and V8_EXPORT.
The unittests test if the trap handler only handles those traps it
is supposed to handle:
* Only handle traps when the thread-in-wasm flag is set.
* Only handle traps of the right type, i.e. memory access violations.
* Only handle traps at recorded instructions.
The tests also test the consistency of the thread-in-wasm flag. I made
one change in the trap handler where that consistency could be
violated.
All tests are executed with the default trap handler provided by V8,
and with the trap handler callback installed in a test signal/exception
handler.
Patchset 1 is the original CL.
R=mstarzinger@chromium.org
Change-Id: I172d94f24cdba4c3a1f7f344825b059dbb59da79
Reviewed-on: https://chromium-review.googlesource.com/c/1351024
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57947}
Fix two bugs:
- Initial configuration of limit allowed to go below the size of already
allocated objects.
- Context disposal without dependend context reset the heap state to not
configured without actually increasing the limit again.
Bug: chromium:843903
Change-Id: Ibdcf69b0b92b800f8919d5cc98186334945d811f
Reviewed-on: https://chromium-review.googlesource.com/c/1355143
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57946}
This adds error functions that receive offsets instead of pc, since the
streaming compiler stores different sections in different buffers, so
computing pointer differences between different sections does not work.
We keep the pc-based methods for now to reduce code-churn and
complexity at the different call sites.
R=ahaas@chromium.orgCC=binji@chromium.org
Bug: v8:8238
Change-Id: I1aa68740bdda93c3341431aa7a81ac01ecfb71bb
Reviewed-on: https://chromium-review.googlesource.com/c/1354463
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57944}
This introduces a dedicated instance type for exception tags. The main
motivation is to reduce their footprint and getting rid of a temporary
workaround that used the {JSObject} type for this purpose.
R=clemensh@chromium.org
BUG=v8:8091
Change-Id: Id5678bce513f2ac086c7380bd803011b11d5050e
Reviewed-on: https://chromium-review.googlesource.com/c/1354464
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57943}
This adds a new target :generated_cc_files which generates all
generated .cc files and is quick to build (~5sec on my machine).
TBR=yangguo@chromium.org
Change-Id: I51485635671b55302b06f1ea300e86ef1745931e
Bug: v8:8526
Reviewed-on: https://chromium-review.googlesource.com/c/1354881
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57941}
This reverts commit 291a602973.
Reason for revert: Unnecessary following f32 support for Liftoff
on arm32.
Original change's description:
> [liftoff][arm] Fix overlapping of F32 and F64 registers in Liftoff
>
> Add a check to bailout in the case when F32 parameters are used for Arm.
>
> Bug: v8:6600, chromium:904026, chromium:904606
> Change-Id: I7f70c0806994a89dca31ef7e0b68f91d68484936
> Reviewed-on: https://chromium-review.googlesource.com/c/1346492
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57741}
TBR=titzer@chromium.org,clemensh@chromium.org,george.wort@arm.com
Change-Id: I98ba43017f521c83b96bbb15e9dc803954dc1eec
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6600, chromium:904026, chromium:904606
Reviewed-on: https://chromium-review.googlesource.com/c/1354467
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57939}
|scope_snapshot_| might not have been cleared if there was a parser error between setting
the snapshot and consuming it. Explicitly clear it at the end of parsing for that case.
Otherwise Scope::Snapshot's destructor will possibly write into the already freed zone.
Bug: chromium:909976
Change-Id: I8469d11f04e7f71528be5cba5663c652cd7eacb2
Reviewed-on: https://chromium-review.googlesource.com/c/1354880
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57938}
This is a reland of d5f4a33eb8
Landing with test disabled for now.
Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}
TBR=v8-mips-ports@googlegroups.comTBR=jgruber@chromium.org
Bug: v8:8464, v8:7202
Change-Id: I260d5ab3bc12c9c4529fb52a297a1040dcaa8ebf
Reviewed-on: https://chromium-review.googlesource.com/c/1354466
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57935}
This refactors Map operations to update the instance descriptors and
the number of own descriptors via the SetInstanceDescriptors bottleneck.
This will allow us to add a special marking barrier for these updates.
Bug: v8:8486
Change-Id: Ie9c746d4bcdd6166d38402622734693fa59faf21
Reviewed-on: https://chromium-review.googlesource.com/c/1354883
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57934}
This CL unifies performance-critical slot processing code that was manually
specifaized for ObjectSlot. Now one templated implementation can be used
for processing both ObjectSlot and MaybeObjectSlot.
Bug: v8:8518
Change-Id: Ia4346a817911f8042459ce579741fe2308ef5e4d
Reviewed-on: https://chromium-review.googlesource.com/c/1354459
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57933}
This supports the use of f32 values for the arm32 port of Liftoff.
Bug: v8:6600
Change-Id: I1fa2782f5a8bc6687a17d2df6e4ec8036b23452c
Reviewed-on: https://chromium-review.googlesource.com/c/1354040
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57932}
Swaps around the checks in CompileLazy to ensure we always enter the
runtime to lazy compile if a function's SFI is uncompiled. This
is necessary with bytecode flushing since the function may have
an optimized code marker in the feedback vector, even if the
bytecode has been flushed, and we don't want to try to optimize
this flushed function.
BUG=v8:8395
Change-Id: I7a348c40146673ba4a8f5e14d06995bbcc141695
Reviewed-on: https://chromium-review.googlesource.com/c/1352277
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57929}
Explicitly disallow implicit casting of ObjectPtr to bool to match
clang's and MSVC's behavior.
Introduce a few function overloads using ObjectPtr instead of Object*.
Fix printing of ObjectPtr for objects-printer.cc and GTest.
Bug: v8:3770
Change-Id: I3c3580d363ae6d9fe8f743c6151abc11a915f05c
Reviewed-on: https://chromium-review.googlesource.com/c/1351245
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57928}
This reverts commit ddaa1f0a0d.
Reason for revert:
Still flaky on windows. Maybe reland and keep skipped on windows?
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win32%20-%20nosnap%20-%20shared/31002https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64/27826
Original change's description:
> Reland "[cpu-profiler] Fix stack iterability for fast C calls with no exit frame"
>
> This is a reland of d5f4a33eb8
>
> Original change's description:
> > [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
> >
> > Before fast C calls, store the current FP and PC on the isolate. When
> > iterating frames in SafeStackFrameIterator, check if these fields are
> > set and start iterating at the calling frame's FP instead of the current
> > FP, which will be in C++ code. We need to do this because c_entry_fp is
> > not set on the Isolate for Fast-C-Calls because we don't build an exit
> > frame.
> >
> > This change makes stack samples that occur within 'Fast-C-Calls'
> > iterable, meaning we can properly attribute ticks within the JS caller.
> >
> > Fast-C-Calls can't call back into JS code, so we can only ever have one
> > such call on the stack at a time, allowing us to store the FP on the
> > isolate rather than the stack.
> >
> > TBR=v8-mips-ports@googlegroups.com
> >
> > Bug: v8:8464, v8:7202
> > Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> > Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> > Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> > Reviewed-by: Alexei Filippov <alph@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#57896}
>
> TBR=v8-mips-ports@googlegroups.com
> TBR=jgruber@chromium.org
>
> Bug: v8:8464, v8:7202
> Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
> Reviewed-on: https://chromium-review.googlesource.com/c/1354042
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57912}
TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
Change-Id: If810648dbf60df2ff70455b6e8ef466136c90145
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8464, v8:7202
Reviewed-on: https://chromium-review.googlesource.com/c/1354461
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57925}
TransitionArray, NormalizedMapCache, DependentCode to the new design.
Bug: v8:3770
Change-Id: I8bd56f231fb62b146e0fb05989418aedb62a628b
Reviewed-on: https://chromium-review.googlesource.com/c/1350287
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57921}
Bug=v8:8075
R=adamk@chromium.org,binji@chromium.org
Change-Id: I11ef5daccd043123b23e60c93ee0df79cabe9ccd
Reviewed-on: https://chromium-review.googlesource.com/c/1342948
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57917}
Two Fixes included to make V8 build work for Windows ARM64.
1. Don't emit ".def" and related macros to define function beginning, because they are invalid for Windows ARM64.
2. Set alignment of data section to 8 which is required for instruction which loads element from v8_Default_embedded_blob_.
Version 7.2.479
Performance and stability improvements on all platforms.
TBR=v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com
Change-Id: I0bfea5dd8ed6c1340d11c13dcc2e492e7b22aa8c
Reviewed-on: https://chromium-review.googlesource.com/c/1352210
Reviewed-by: v8-ci-autoroll-builder <v8-ci-autoroll-builder@chops-service-accounts.iam.gserviceaccount.com>
Cr-Original-Commit-Position: refs/heads/7.2.479@{#1}
Cr-Original-Branched-From: a8152aac7049aed0cc7e7437898de2fce2787288-refs/heads/master@{#57863}
Bug: chromium:893460
Reviewed-on: https://chromium-review.googlesource.com/c/1352791
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Tom Tan <Tom.Tan@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#57915}
This is a reland of d5f4a33eb8
Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}
TBR=v8-mips-ports@googlegroups.comTBR=jgruber@chromium.org
Bug: v8:8464, v8:7202
Change-Id: I5f37ded4ea572e8e9890ba186aa3d74a0dfc1274
Reviewed-on: https://chromium-review.googlesource.com/c/1354042
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57912}
This implements arithmetic operations on i64, as well as eqz
and conditional set for the arm32 port of Liftoff.
Bug: v8:6600
Change-Id: I21dc0f820e1429392599a5813c44b938c38093a2
Reviewed-on: https://chromium-review.googlesource.com/c/1348082
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57910}
This allows f32 floor, ceil, trunc, and nearest_int to use a C fallback in
Liftoff in the same way that f64 rounding can.
Bug: v8:6600
Change-Id: I8b88d806633bcfe2d2dfac9defaf60e551bf21b1
Reviewed-on: https://chromium-review.googlesource.com/c/1353898
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57909}
This saves a few control merges in Liftoff, and might also generate
smaller graphs in Turbofan.
R=titzer@chromium.org
Bug: v8:6600, v8:8423
Change-Id: Ice921f8b048809bc38b820b94688f482e67bd386
Reviewed-on: https://chromium-review.googlesource.com/c/1354039
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57907}
This makes changes to the generic code in Liftoff to support f32 values on the
arm32 port, but does not implement any handling of them in practice.
Bug: v8:6600
Change-Id: Ia1587c4eee0158ef6b0caa46b6b212cb96ef579f
Reviewed-on: https://chromium-review.googlesource.com/c/1352287
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57902}
This reduces wasm's ABI on Arm to only using the even-numbered float registers
in anticipation of Liftoff supporting f32 values on the arm32 port. This is due
to Liftoff assuming a one-to-one mapping between double and float registers.
The ABI must be restricted in order to allow Liftoff compiled and Turbofan
compiled functions to call each other. Turbofan continues to use all float
registers internally however.
Bug: v8:6600
Change-Id: I47d91b8216136e57f42fd9665ed57ec631eb0374
Reviewed-on: https://chromium-review.googlesource.com/c/1352278
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57901}
This reverts commit d5f4a33eb8.
Reason for revert: Seems to cause a no snapshot build failure - https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20nosnap%20-%20debug/21967
Original change's description:
> [cpu-profiler] Fix stack iterability for fast C calls with no exit frame
>
> Before fast C calls, store the current FP and PC on the isolate. When
> iterating frames in SafeStackFrameIterator, check if these fields are
> set and start iterating at the calling frame's FP instead of the current
> FP, which will be in C++ code. We need to do this because c_entry_fp is
> not set on the Isolate for Fast-C-Calls because we don't build an exit
> frame.
>
> This change makes stack samples that occur within 'Fast-C-Calls'
> iterable, meaning we can properly attribute ticks within the JS caller.
>
> Fast-C-Calls can't call back into JS code, so we can only ever have one
> such call on the stack at a time, allowing us to store the FP on the
> isolate rather than the stack.
>
> TBR=v8-mips-ports@googlegroups.com
>
> Bug: v8:8464, v8:7202
> Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
> Reviewed-on: https://chromium-review.googlesource.com/c/1340241
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
> Reviewed-by: Alexei Filippov <alph@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57896}
TBR=alph@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,martyn.capewell@arm.com,v8-arm-ports@googlegroups.com,v8-mips-ports@googlegroups.com,ibogosavljevic@wavecomp.com
Change-Id: I85f846e57b6fa845e7770c616435cebffdb2a245
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8464, v8:7202
Reviewed-on: https://chromium-review.googlesource.com/c/1352302
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57899}
The test was flaky because it assumed that AllocatedAssemblerBuffer
would eventually return an address within near-call range. Rarely, this
did not happen (within the retry limit), and so the test would crash.
This fix allocates a single, kMaxWasmCodeMemory-sized buffer for the
test, and generates call sequences within that buffer.
BUG=v8:8245
Change-Id: I4b44d897c6cbda15a18ab992fa57805de3b2db29
Reviewed-on: https://chromium-review.googlesource.com/c/1347484
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jacob Bramley <jacob.bramley@arm.com>
Cr-Commit-Position: refs/heads/master@{#57898}
Before fast C calls, store the current FP and PC on the isolate. When
iterating frames in SafeStackFrameIterator, check if these fields are
set and start iterating at the calling frame's FP instead of the current
FP, which will be in C++ code. We need to do this because c_entry_fp is
not set on the Isolate for Fast-C-Calls because we don't build an exit
frame.
This change makes stack samples that occur within 'Fast-C-Calls'
iterable, meaning we can properly attribute ticks within the JS caller.
Fast-C-Calls can't call back into JS code, so we can only ever have one
such call on the stack at a time, allowing us to store the FP on the
isolate rather than the stack.
TBR=v8-mips-ports@googlegroups.com
Bug: v8:8464, v8:7202
Change-Id: I7bf39eba779dad34754d5759d741c421b362a406
Reviewed-on: https://chromium-review.googlesource.com/c/1340241
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57896}
The MemoryInitImmediate and TableInitImmediate read a Memory/Table
index, followed by a segment index. If reading the first index fails, we
need to stop reading, or the decoder will read past the end.
Bug: chromium:907324
Change-Id: I3eb46c08d03e3b2e44ed4081d307b32c799abcec
Reviewed-on: https://chromium-review.googlesource.com/c/1351502
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57889}
waiting_ flag is now set inside a lock to prevent data race. This means
that waiting_ is false when callback is called at start of wait. To deal
with the new behavior, NotifyWake now always tries to Notify and sets
interrupted_ flag which will be handled by any future wait.
R=binji@chromium.org
BUG=v8:8497
Change-Id: Ia4fd39bcf18875d9be21bafc176ab562b083e68b
Reviewed-on: https://chromium-review.googlesource.com/c/1351237
Commit-Queue: Aseem Garg <aseemgarg@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57887}
which are no longer derived from FixedArray and therefore IsFixedArray()
check no longer includes Contexts.
Bug: chromium:908877
Change-Id: I3aed0d38f5b1c00c9e27b7d5b6d29cdd5666ba86
Reviewed-on: https://chromium-review.googlesource.com/c/1352280
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57883}
That reduces the overhead of ParseAssignmentExpression at the cost of a few
more branches in the possible arrow head paths.
This also fixes the case where an outer scope of an arrow function didn't call eval
but a parameter initializer does. Previously the outer scope was also marked as
calling eval, causing worse performance. (Unlikely to happen though.)
Change-Id: I5263ef342f14e97372f5037fa659f32ec2ad6d34
Reviewed-on: https://chromium-review.googlesource.com/c/1352275
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57881}
This avoids leaving the heap in an invalid state if a GC occurs during
population of the cloned property array, as is done in other IC
builtins.
BUG=chromium:904167, v8:7611
R=jkummerow@chromium.org, ishell@chromium.org
Change-Id: I0350ed2d65b72e299f7109b7d5aa86331f60e940
Reviewed-on: https://chromium-review.googlesource.com/c/1350282
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57879}
This CL introduces Tagged_t and AtomicTagged_t typedefs which represent
the storage type of tagged values in V8 heap.
Bug: v8:7703
Change-Id: Ib57e85ea073eaf896b6406cf0f62adcef9a114ce
Reviewed-on: https://chromium-review.googlesource.com/c/1352294
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57878}
This patch refactors the parsing of object literal properties and
class literal properties, putting the out parameters into a pointer of
struct `ParsePropertyInfo`. This struct is also aware of its potition
so `ParsePropertyName()` can also use this information to error
when parsing a private name in an object literal. It also makes
sure that the `ClassLiteralProperty::Kind` are all inferred
from the `ParsePropertyKind` and get used right away instead of
being passed around as out parameters.
Bug: v8:8330
Change-Id: I4c52592dfcaa3c8df30c4aba4c46e5c675acb394
Reviewed-on: https://chromium-review.googlesource.com/c/1347904
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57876}
When restarting a frame on returning from a debug break, we are going
to drop the current function frame, therefore the return value and
next bytecode are not going to be used. Special case these situations
since with bytecode flushing it is possible the SFI for the
executing function might have been flushed (if edited by liveedit)
which causes failures when trying to read from the bytecode array.
BUG=v8:8395
Change-Id: I18adaa5d91c244e6d13e8703ed41c300f793681d
Reviewed-on: https://chromium-review.googlesource.com/c/1352270
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57875}
Only log incrementally deserialized maps with --trace-maps instead of
iterating the whole heap and print all existing maps on every partial
deserialization for new contexts. This should greatly improve
performance of --trace-maps on websites with many iframes.
- Add helpers to share code: LogNewObjectEvents, LogScriptEvents,
LogNewMapEvents
- Link AllocationSites before any GC
Change-Id: I5322421a83e057518f871540691511c80bc7786a
Reviewed-on: https://chromium-review.googlesource.com/c/1342029
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57874}
Unfortunately the previous strategy was slower but more memory efficient. For now simply revert.
Revert "[zone] Use 32kb instead of 1MB as high zone page size"
Revert "[zone] Get rid of the Zone's segment pool"
Revert "[zone] Further simplify zone expansion, use single default page size"
Bug: chromium:908359
Change-Id: I649542e7e61eef0c14a26ffd21039e8340ab4d04
Reviewed-on: https://chromium-review.googlesource.com/c/1351027
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57872}
This CL fixes allocation size alignment violation when allocating store buffer.
If the actual CommitPageSize happens to be bigger than kMinExpectedOSPageSize
we will have a bit of memory wastage but that's a fair trade-off for having
fast store buffer overflow check in write barriers.
Change-Id: I1d775aa8b203cb198e8332477b0bc2befcd9b006
Reviewed-on: https://chromium-review.googlesource.com/c/1351007
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57871}
A pointer to MicrotaskQueue is stored in a NativeContext field as a Smi,
that is discouraged. This CL replaces it to use the dedicated field.
Bug: v8:8124
Change-Id: I5a770624b3a9c922051e86243da2ae216aaacf3a
Reviewed-on: https://chromium-review.googlesource.com/c/1351855
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57870}
This unifies the order of i-cache flushing and permission changing
throughout V8. According to cctest/test-icache flushing after the
permission change is not robust on some ARM32 and ARM64 devices.
There have been observed failures of {TestFlushICacheOfExecutable} on
some devices. So far there haven't been any observed failures of the
corresponding {TestFlushICacheOfWritable} test.
Also the order of flushing before the permission change is the natural
order in which the GC currently performs operations. Until we see
concrete data substantiating the opposite, the following is the
supported and intended order throughout V8:
exec -> perm(RW) -> patch -> flush -> perm(RX) -> exec
This CL tries to establish said order throughout the codebase.
R=ulan@chromium.org
TEST=cctest/test-icache
BUG=v8:8507,chromium:845877
Change-Id: Ic945082e643aa2d142d222a7913a99816aff4644
Reviewed-on: https://chromium-review.googlesource.com/c/1351025
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57869}
Pushing unresolved variables at the front was an optimization for the case
where we didn't have an end pointer. That forces us to do an O(<new elements>)
walk to rescope variables. The implementation was more generic and even did
O(<all elements>). Now that we have an end pointer we can simply push at the
end and MoveTail which is O(1).
Change-Id: I65cd5752b432223d95cd529452a064d8dcc812e1
Reviewed-on: https://chromium-review.googlesource.com/c/1351010
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57868}
This reverts commit fac6f63eb8.
Reason for revert: https://bugs.chromium.org/p/chromium/issues/detail?id=907479
Original change's description:
> Use CopyElements (which uses memcpy) to copy FixedDoubleArray.
>
> This improves the performance of ExtractFixedArray and
> CloneFastJSArray for double arrays, which in turn improve the
> performance of cloning double arrays with slice() or spreading.
>
> This, however, does not improve performance of spreading holey
> double arrays, because spreading needs extra work to convert
> holes to undefined.
>
> Bug: v8:7980
> Change-Id: Ib8aed74abbb0b06982a3b754e134fa415cb7de2d
> Reviewed-on: https://chromium-review.googlesource.com/c/1280308
> Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> Commit-Queue: Hai Dang <dhai@google.com>
> Cr-Commit-Position: refs/heads/master@{#56680}
TBR=mvstanton@chromium.org,neis@chromium.org,sigurds@chromium.org,dhai@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:7980, chromium:907479
Change-Id: Iacf37fa3276345fe8e264fe976d296b015ed6790
Reviewed-on: https://chromium-review.googlesource.com/c/1351003
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57864}
This reverts commit 4644b32e02.
Reason for revert: Link errors on win64: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Win64%20-%20debug/25950
Original change's description:
> [wasm] Add more unit tests for trap handler
>
> The unittests test if the trap handler only handles those traps it
> is supposed to handle:
> * Only handle traps when the thread-in-wasm flag is set.
> * Only handle traps of the right type, i.e. memory access violations.
> * Only handle traps at recorded instructions.
>
> The tests also test the consistency of the thread-in-wasm flag. I made
> one change in the trap handler where that consistency could be
> violated.
>
> All tests are executed with the default trap handler provided by V8,
> and with the trap handler callback installed in a test signal/exception
> handler.
>
> Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
> Reviewed-on: https://chromium-review.googlesource.com/c/1340246
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57858}
TBR=mstarzinger@chromium.org,ahaas@chromium.org,mark@chromium.org
Change-Id: Iac2f20c73744226885ea1810813863a21c5faf8c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/1351021
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57861}
The unittests test if the trap handler only handles those traps it
is supposed to handle:
* Only handle traps when the thread-in-wasm flag is set.
* Only handle traps of the right type, i.e. memory access violations.
* Only handle traps at recorded instructions.
The tests also test the consistency of the thread-in-wasm flag. I made
one change in the trap handler where that consistency could be
violated.
All tests are executed with the default trap handler provided by V8,
and with the trap handler callback installed in a test signal/exception
handler.
Change-Id: I03904bb6effd2e8694d3f4d1fbf62bc38002646e
Reviewed-on: https://chromium-review.googlesource.com/c/1340246
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57858}
and Relaxed_Store(int, ...) by migrating the only call site
to using slot increment/decrement instead of offset calculations.
Also use SlotBase::location() more consistently.
Bug: v8:8238
Change-Id: I3099884a2a9e05041114205e7fb81691261afe19
Reviewed-on: https://chromium-review.googlesource.com/c/1349731
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57852}
The style guide says that only `int` should be used of the builtin
integer types. Instead, we should use the stdint types.
See https://google.github.io/styleguide/cppguide.html#Integer_Types
Change-Id: I1af53a3bceefbfed85589b74a602c8ebe1c7ee25
Reviewed-on: https://chromium-review.googlesource.com/c/1342663
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57851}
This CL makes it easier to organize the Context classes hierarchy and
simplifies Context class definition.
Bug: v8:8238
Change-Id: I65b8255daf255649c597dc195edf436d9471e3ea
Reviewed-on: https://chromium-review.googlesource.com/c/1350109
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57848}
Add a path into embedder tracing on allocation. This is safe as as Blink
is not allowed to call into V8 during object construction.
This is a reland of caed2cc033.
Also relands the cleanups of ce02d86bf2.
Bug: chromium:843903
Change-Id: Ic89792fe68337c540a1a93629aee2e92b8774ab2
Reviewed-on: https://chromium-review.googlesource.com/c/1350992
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57847}
This patch gives DescriptorArray its own visitor id and its
own layout that is independent from the layout of WeakFixedArray.
This allows us to use raw 16-bit integers for keeping track of
the number of descriptors (total, non-slack, and marked).
As a side-effect, we save one word per descriptor array on 64-bit.
v8:8486
Change-Id: If8389dde446319e5b3491abc948b52539dba235c
Reviewed-on: https://chromium-review.googlesource.com/c/1349245
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57845}
Flag flip to enable this feature.
R=mstarzinger@chromium.org
Bug: v8:8423
Change-Id: I59ee8c49c2f0323a32e8c7e6c9cf8d929b4a8bb4
Reviewed-on: https://chromium-review.googlesource.com/c/1349239
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57844}
This implements copy sign for both the arm32 and arm64 port of Liftoff.
Bug: v8:6600
Change-Id: Ic822e75417c6b911a03e8e9a2d6d59a98fbc3d18
Reviewed-on: https://chromium-review.googlesource.com/c/1348430
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57843}
This implements arithmetic operations on f64, as well as
conditional set for the arm32 port of Liftoff.
Bug: v8:6600
Change-Id: Ia060652e5292ed94da8a0ba656bddbcc13d9f610
Reviewed-on: https://chromium-review.googlesource.com/c/1348349
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57841}
In the process, use the correct ArrayPrototype* naming convention for
the slice and splice builtins.
Change-Id: I1f85e5512dbde8f92e7c764aef9f137d0a6693e0
Reviewed-on: https://chromium-review.googlesource.com/c/1350869
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57840}
CL "[Cleanup] String::GetChars() should assert against heap allocation"
was missing one DisallowHeapAllocation declaration.
(I had Michi look over the change, as the callstack actually comes from
the garbage collector. Marja, I put you on TBR).
Thanks all..
TBR=marja@chromium.org
No-tree-checks: true
No-try: true
Bug: v8:8238
Change-Id: I71333124bc4bcef945430fc5242a516b6ed277ff
Reviewed-on: https://chromium-review.googlesource.com/c/1351013
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57839}
This CL adds new Wasm import call kinds that correspond to various
math functions that can be imported from JavaScript, such as trigonometry.
Instead of calling a special import wrapper that converts arguments
to tagged values by boxing, we can now generate calls to little WASM
stubs that contain a single WASM bytecode each.
R=mstarzinger@chromium.org
BUG=v8:8423
Change-Id: I59b1be2dd36d190a8b6c98b88c86cecc0ca7f4a2
Reviewed-on: https://chromium-review.googlesource.com/c/1349279
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57835}
The flag is only available in d8 and should therefore not be in
flag-definitions.h.
R=clemensh@chromium.org
Bug: v8:8238
Change-Id: Idd69914cea03e736cf3b156b5961d583a7b5352c
Reviewed-on: https://chromium-review.googlesource.com/c/1349244
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57829}
We cannot assign a meaningful type to Promise#catch() or
Promise#finally(), since they both return whatever the invocation of
'then' on the receiver returns, and that is monkeypatchable by arbitrary
user JavaScript.
Bug: chromium:908309, v8:7253
Change-Id: Ib15f81c366938a1b1f10be6c6af85c1f3374b898
Reviewed-on: https://chromium-review.googlesource.com/c/1350789
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57828}
